Your manual workaround (escaping " < >) is safe, but note it's
effectively just escapeHtml=true again, so <b> will render literally
rather than bold. Fine if you don't actually need the formatting on
those fields.
Is correct, as I was escaping untrusted input (which I had missed on an
action) and now shows :
The answer [<script>alert('OK')</script>] is not correct. Please try again.
rather than the execution.
###
> <s:property value="%{sanitize(actionError)}"/>
Seems a safer way, as would catch any missed action escaping. Note not
all the message is untrusted only the getSearchString() parameter!
addError("error.search.entries", getSearchString());
error.search.entries=No entries were found using the term <b>{0}</b>.
Please try again.
<s:iterator var="actionError" value="actionErrors">
<%-- <li><s:property value="#actionError"
escapeHtml="false" /></li> --%>
<li><s:property value="%{sanitize(#actionError)}"/></li>
</s:iterator>
But would this work? Doesn't the tag then enforce escapeHtml="true".
###
>So WW-5639 makes the tag's behaviour predictable and stops the
>corruption
Not sure I understand this.
escapeHtml -> escapeJavaScript ie :
<s:property value="#actionError" escapeHtml="false"
escapeJavaScript="true" />
No entries were found using the term <b>testme<\/b>. Please try again.
An unterminated <b> so the following text would still be bold.
###
On 29/06/2026 20:27, Lukasz Lenart wrote:
sob., 27 cze 2026 o 10:58 Greg Huber <[email protected]> napisał(a):
If we can fix this then good.
If I understand it correctly, escapehtml=false, then apply either
escapeJavaScript or escapeXml or escapeCsv ?
Yes, exactly that's what WW-5639 proposes. The four flags become
mutually exclusive and exactly one escaper is applied, by first-match
precedence:
escapeHtml -> escapeJavaScript -> escapeXml -> escapeCsv
Since escapeHtml defaults to true, the default (HTML-escape only)
doesn't change. The only outputs that change are the broken combos
that were already producing corrupt double-/cross-escaped results,
like the <b><\/b> you hit.
I did try this, (escapeHtml -> escapeJavaScript) but was left with the
unterminated html
the quick fix I used for the layout problem, was to drop
escapeJavaScript add an additional escape on any field that returned
into the response (with escapehtml=false)
s = Strings.CS.replace(s, "\"", """);
s = Strings.CS.replace(s, "<", "<");
s = Strings.CS.replace(s, ">", ">");
Probably not the correct way comparing with commons.text
escapeEcmaScript (the experts), but escaping js correctly and make it
play nicely seems a minefield.
I want to flag two things, because I don't think this ticket gives you
what you're actually after:
escapeJavaScript is not XSS protection. It escapes only ' " \ / and
control chars, it does NOT touch <, > or &. So escapeHtml=false +
escapeJavaScript=true still emits a live <script> into the page. The
real exposure is escapeHtml=false itself, which outputs raw HTML and
is unsafe unless the value is fully trusted. So the "warning" we
discussed shouldn't say "set escapeJavaScript=true", that's a false
sense of safety.
"Allow <b>/<strong>, block <script>" can't be done with these flags.
Escaping HTML and allowing HTML markup are opposite output contexts -
that's why escapeHtml=false + escapeJavaScript=true mangles the
closing tags. What you want is an allowlist HTML sanitizer (e.g. OWASP
Java HTML Sanitizer), applied to the value before output, with
escapeHtml=false on a value you've already sanitized. That keeps
<b>/<strong>/<em> and strips/encodes <script>. The property tag's
escape flags aren't the right tool for it.
Your manual workaround (escaping " < >) is safe, but note it's
effectively just escapeHtml=true again, so <b> will render literally
rather than bold. Fine if you don't actually need the formatting on
those fields.
So WW-5639 makes the tag's behavior predictable and stops the
corruption, plus updates the docs/JavaDoc and adds a devMode warning
when more than one flag is set. It just won't, by itself, give you
"formatting yes, scripts no" that needs the sanitizer.
You can implement a function and then call it via %{} expression like this:
<s:property value="%{sanitize(actionError)}"/>
Cheers
Łukasz
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
