OWASP recommends HSTS max-age=63072000 recommendation

What is the name of the domain?

https://example.com

What is the error number?

n/a

What is the error message?

n/a

What is the issue you’re encountering

No issue just a question.

What steps have you taken to resolve the issue?

Just a question

What are the steps to reproduce the issue?

According to the OWASP cheat sheet the recommended header has a max-age of 2 years:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

But the dropdown in the HSTS settings only goes up to 12 months? I realise I can set this manually through the use of other rules (e.g. response rules) but I’d prefer to use the UI. Is there a plan to increase the dropdown to 24 months? Or should the max-age recommendation in OWASP be ignored?

Screenshot of the error

1 Like

I would unfortunately attribute this one to Cloudflare, as being the party that is slacking.

I can’t confirm nor deny that though.

However, is 24 months enough?

I believe that recommendation is quite unfortunate in certain ways.

I wouldn’t ignore it though, - but I would consider it as a “recommended MINIMUM”.

Twitter, to mention one example, or X, or whatever they call themself today, have for years been running with “max-age=631138519”, that would translate to around 20 years.

If we’re looking through OWASP, and the mention on their site, that says:

Browser Support

As of September 2019 HSTS is supported by all modern browsers, with the only notable exception being Opera Mini.

I’m now wondering, -

You had an user that visited your website in June 2020, but hasn’t been on your site since then.

Now, the user returns to your website, after a long while, but we’re now talking July 2024, or, more than 4 years later.

Your HSTS has expired a very long time ago, so now, the user may actually connect insecurely to your website at the first visit they are making now.

HSTS would have kept this user on HTTPS, if you had done “max-age=631138519” (20 years), but not with the 24 months / 2 years one you’re describing.

48 months / 4 years wouldn’t have helped the user either.

(What is your goal?)

I was just curious really and I was unsure whom to “trust” (if that’s the correct word in this instance). I just wondered if any of these max-age figures are backed up by any “real” data? Or are they just nice round numbers to set it too?

They aren’t. Like the ‘forced’ recommendations to change user passwords every 30 or 90 days.

12 months is more than enough. I struggle to identify a significant security benefit (or really any benefit) from a 2 year or 5 year or whatever header. Especially when you can simply set the preload value.

Right, because if I boot up my iMac G3 I’ve had in storage for two decades, it’s important it still attempts to connect over HTTPS.

My cynical opinion is that by capping it at one year, that’s the longest time someone’s going to shoot themself in the foot if they realize they’ve made a mistake in enabling HSTS.

1 Like

I believe regardless whom you ask, you may find “opinionated” opinions, pointing in different directions.

Having the two year one, but four years ago, including the “preload” value, could also have done the trick, assuming the following criteria:

  1. You had also added your domain to the HSTS preload list back then.

  2. You had kept the HSTS values for the whole time, and not been removed for failing to keep up the requirements for the HSTS preload list.

  3. The browser was updated well-enough to have the updated HSTS preload list, including your domain.

Two decades would be a future issue though

I was however quite surprised the first time I saw the extremely long HSTS.

With the maximum life time of domain registrations being 10 years, I could also see opinions against anything above that, such as for example the 20 years, as that could hit a new registrant of the same domain name.

Anyway, -

I’m just trying to say, that I do see a good point, with a (very) long HSTS.

Preferably, it would be combined with the “preload” value, AND the HSTS preload list.

1 Like

I don’t, but we can agree to disagree.

If I really, really needed a domain to always be served over TLS and never do an http request because the risk is really just that high… I’d buy a domain on a TLD which requires / forces HTTPS.