Primary domain redirects do not support HSTS preload standard

Continuing the discussion from Improvements to TLS and primary domain redirects for non-static assets:

Breaking out the primary domain redirect HSTS discussion to its own thread here.

Primary domain redirects appear to not have a fixed HSTS (Strict-Transport-Security) header and do not follow the settings in a site’s _header or netlify.toml file. The header supplied in primary domain redirect responses is Strict-Transport-Security: max-age=31536000 but the HSTS preload standard requires serving Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. It is does not appear possible to serve this header in the primary domain redirect response as the headers appear to be hardcoded.

Is there an existing method for making primary domain redirects comply with the HSTS preload standard?

Hi there,

Our team has a fix for this in progress - allowing HSTS preload to work even after the change in the other post you mention broke it.

I don’t know how soon it will be here - I’ve seen the code in progress, and I think not tested yet, and not super simple - but today, your only way to get that working is to serve your site from the primary custom domain of your bare domain (which is usually suboptimal, but if hstspreload is more important than performance, you could choose to swap them for now, and it should work better, was my understanding.)

Please let me know if not and I’ll consult further with the team.

3 Likes

My site happens to have its canonical name use the www subdomain prefix for years, so I would rather not change that by switching to the apex domain as the canonical name.

I don’t know how long this has been broken or whether it was ever working as I believe my site was submitted to the HSTS preload list before moving to Netlify but I don’t remember and did not keep any records.

If this issue has not existed for long, then I think the risk of being deleted from the HSTS preload list is small. If a fix can be in production in the next few weeks or so, I think that would be fine.

In any case, thank you for the response and glad to hear that a fix is in the works.

Heya @cataclysm , we did ship a fix for this! Would you mind verifying if things are again working as you intended? You would have to redeploy your site (at some point, since a few days ago, when we quietly put the fix live for our non-enterprise CDN - Oct 14)

If not, I can tell you don’t want to share your sitename publicly based on your consistent use of example.com , but if you see it not working as intended, could you share the x-nf-request-id ([Support Guide] Netlify Support asked for the 'x-nf-request-id' header? What is it and how do I find it?) for a request that didn’t work? Nobody except our staff will be able to correlate that with a hostname :slight_smile:

PS: This test requested is “use with your existing configuration”, not “change your primary custom domain as you’ve said you don’t want to do”.

Thanks in advance for your help!

2 Likes

It’s working correctly now. Thanks!