Re: check response on app

>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, "\"", "&quot;");
>>    s = Strings.CS.replace(s, "<", "&lt;");
>>    s = Strings.CS.replace(s, ">", "&gt;");
>>
>> 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]
>