Do not enable HSTS by default

Feature request

Currently, HSTS is enabled by default with a very long period, subdomains included, and preload enabled. This has some problems:

• A user may not know what HSTS means, and accidentally ruined all his non-HTTPS subdomains by using the generated config.
• The max-age is too long. For anyone who want to try HSTS, he should start by using short periods to test.
• If a user added two sites: “example.com” and “foo.example.com”, and explicitly disabled HSTS for “foo.example.com”, it still gets HSTS by default because “example.com” enabled HSTS for all subdomains by default. This behavior is just wrong.
• Preloading should be opt-in. If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, do not include the preload directive by default.

So, my suggestion is to disable HSTS by default (or at least warn people about includeSubDomains). User should only enable HSTS if they know what they are doing.

[MattIPv4]

HSTS is a huge step in the right direction for a more secure web – most sites now use HTTPS by default, some TLDs even have HSTS forced (.dev for example), so I think it is right for a tool designed to provide the best practices to default to having HSTS enabled.

The max-age on HSTS is recommended to generally be long, somewhere in the range of 120 days to a year. nginxconfig is designed to apply the best practices to the generated nginx config files, so we use 1 year for the max-age on the HSTS header.

However, I do agree about the dangers of not correctly explaining the use of includeSubDomains as well enabling preload by default (these decisions predate me working on the project) – I think we can address the includeSubDomains issue by adding some explainer text next to that setting for those that may need HTTP subdomains, and we can make preload disabled by default.

[MattIPv4]

Should be fixed as soon as the latest push deploys: