On 3/24/20 2:25 PM, Christopher Schultz wrote:
I don't understand exactly how X-Frame-Options (which is what the
HttpHeaderSecurityFilter is configuring) is being used by your
application, but I believe X-Frame-Options is essentially being
replaced by various features of Content-Security-Policy. You may want
to talk to your engineers about using one of those versus the other;
you may want to discontinue using the "anti click-jacking" features of
this filter altogether in favor of something else.
Dear Mr. Schultz (et al):
Thanks. Our webapp team combined your answer with what we could glean
from the customer's security audit, and has come up with a solution
involving a Content-Security-Policy, using a class he added to the
webapp. I'm not sure, but I think it can be built into the WAR file.
On our own Tomcat server, we have another webapp that cannot have
clickjack protection via a HTTPHeaderSecurity filter with
<param-name>antiClickJackingOption</param-name>
<param-value>SAMEORIGIN</param-value>
because it's specifically designed to go into a frame, in a page served
from an entirely different server. Is that what the "ALLOW-FROM" option
and the associated "antiClickJackingUri" parameter are for?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
