You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lucky's ForceSSLHandler class adds the HTTP Strict Transport Security (HSTS) header to HTTP requests only, when it needs to instead add it to HTTPS requests only.
I discovered this after enabling the force TLS redirect and HSTS settings as documented in the generated config/server.cr, using:
Lucky::ForceSSLHandler.configure do |settings|
settings.enabled =Lucky::Env.production?
settings.strict_transport_security = {max_age:1.year, include_subdomains:true}
end
I was looking into submitting my site for the HSTS preload list (so that on supported browsers, an insecure request doesn't need to be made at all), when I found my site was ineligible. The result is the same for Lucky's site:
The information provided in that message and the MDN docs (which are linked to from the Lucky docs, ironically) says that the HSTS header needs to be provided when the site is requested over HTTPS only. Which makes sense, as an HTTP request could be tampered with to remove the header.
Lucky's
ForceSSLHandler
class adds the HTTP Strict Transport Security (HSTS) header to HTTP requests only, when it needs to instead add it to HTTPS requests only.I discovered this after enabling the force TLS redirect and HSTS settings as documented in the generated
config/server.cr
, using:I was looking into submitting my site for the HSTS preload list (so that on supported browsers, an insecure request doesn't need to be made at all), when I found my site was ineligible. The result is the same for Lucky's site:
The information provided in that message and the MDN docs (which are linked to from the Lucky docs, ironically) says that the HSTS header needs to be provided when the site is requested over HTTPS only. Which makes sense, as an HTTP request could be tampered with to remove the header.
I checked what the current behaviour is:
And yes, the
Strict-Transport-Security
was present in the wrong response.Fixing it should be relatively simple, even for a Crystal-newbie like myself, so I'll start on a PR now.
btw, you folks really should provide info on somewhere to report security vulnerabilities =P e.g. https://securitytxt.org/
Cheers for the awesome framework!
CC @jwoertink - just a heads up since you implemented it in #734 ;)
The text was updated successfully, but these errors were encountered: