I'm looking into the docs for this filter in a bit more depth, and
something I see doesn't make any sense:
The Tomcat 9 doc says:
hstsEnabled
Will an HTTP Strict Transport Security (HSTS) header
(Strict-Transport-Security) be set on the response for
secure requests. . . . If not specified, the default
value of true will be used.
As I read this, that would seem to mean that if I have the filter block
for httpHeaderSecurity uncommented, and the *only* parameter I have in
the init-param clause is antiClickjackingOption, the mere fact that the
filter is enabled will send an HSTS header (albeit with a max age of
zero). And yet, if I have the browser console up and looking at headers,
when I load the sign-on page for the webapp, there's no
"Strict-Transport-Security" header to be found. Am I misunderstanding
the doc?
On 10/13/25 1:42 PM, Olaf Kock wrote:
You have almost no chance to screw it up (provided
you use standard ports 80 and 443)
and
HSTS is /not/ tied to any certificate. It's literally
just the single "s" that's added to URLs. The rest of
the handling is 100% standard no matter any HSTS setting
And yet, something I read on Friday, at
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security>
tells me that setting HSTS with my "guinea pig" server would be bad. As
in "Don't cross the streams" bad.
If a TLS warning or error, such as an invalid certificate,
occurs when connecting to an HSTS host, the browser does
not offer the user a way to proceed or "click through"
the error message, which would compromise the intention
of strict security.
Doesn't that mean that HSTS would block the browser from even offering
one the option of overriding an out-of-date cert? (the one on my "guinea
pig" server is 5 years out-of-date, and up until I looked at it just
now, I thought it was probably also wrong-domain-name). I *do* have a
permanent override for it in Firefox, though. But would HSTS kill that, too?
I did just re-read what I'd read at cheatsheetseries.owasp.org on
Friday, about persistent effects, and now realize that I was looking at
the "preload" option.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
