HSTS default max-age parameter update

[mark-szabo]

Updating default max-age parameter of the Strict-Transport-Security header to 1 year.

1 year is the industry standard. IETF is using 1 year in the sample (https://tools.ietf.org/html/rfc6797#section-6.1.1) and sonarwhal is throwing an error if it is shorter than 18 weeks (https://sonarwhal.com/docs/user-guide/rules/rule-strict-transport-security/#what-does-the-rule-check).

[dnfclas]

All CLA requirements met.

[Tratcher]

@blowdart

[blowdart]

A sample doesn't make it an industry standard (and the following sample indicating 1 year is another indicating 6 months). Furthermore section 11.2 of the RFC says we can consider setting the default to zero,

Additionally, server implementers should consider employing a default max-age value of zero in their deployment configuration systems. This will require deployers to willfully set max-age in order to have UAs enforce the HSTS Policy for their host and will protect them from inadvertently enabling HSTS with some arbitrary non-zero duration.

OSWAP has a sample with a very short max-age in case there are problems during rollout.

So, the "industry standard" varies, according to circumstances, or the maturity of the roll out. So my feeling is 30 days is a compromise, one which the developer can override once they're confident in their configuration, a year by default is problematic.

[mark-szabo]

@blowdart in this case we should update the ASP.NET Core project templates to include the configuration code (or a comment at least) as that's not that straightforward IMHO and with this default setting we are just encouraging developers to leave it on 30 days which is not that great...

// Change this to a longer period after you are confident with your configuration
services.Configure<HstsOptions>(options =>
{
    options.MaxAge = TimeSpan.FromDays(30);
});

[blowdart]

That's fair enough, do you want to open a bug in the templating repo for it?

[mark-szabo]

Yeah, sure!