3

Referencing this: https://hstspreload.org/

There's a bunch of stuff about making really sure that it all works before you get them to pre-load it:

  • when testing first test with a max-age of 5 minutes, then ramp up to 1 week, & 1 month.
  • They say if you're making a framework or library, then make preload be opt-IN.

I assume that this is mainly about people retro-fitting preloaded HSTS to existing systems, and then discovering that some legacy part of the system doesn't support HTTPS?

However, I'm just creating a greenfield site. So I think I should be able to configure the pre-load up-front, and ensure that everything I develop supports HTTPS.

Is there any reason that a modern greenfield site would be unable to support HTTPS anywhere?

Is there any other drawback to doing this?

Very similar question, with a more Code-/Programming-targetted angle posted in StackOverflow: https://stackoverflow.com/questions/54158239/are-there-any-practical-risks-to-enabling-preloaded-hsts-on-greenfield-net-cor

Brondahl
  • 169
  • 5

1 Answers1

2

The reason to be careful with preload is the case for when you think all your sites have converted to HTTPS, but then it turns out marketing uses some CRM from 2005 that still runs over HTTP. When you turn on HSTS with includeSubdomains, their tool will no longer work.

If you have a new domain you still have total control over it, and it is unlikely that you break some HTTP site by preloading HSTS. So in your case, I think it is acceptable to preload HSTS from the start.

Sjoerd
  • 30,589
  • 13
  • 80
  • 107