HSTS Preloading Should Be Opt-In

Hey there :wave:,

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. We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list by the time they find they need to remove HSTS to access certain subdomains. Removal tends to be slow and painful for those sites.

Projects that support or advise about HSTS and HSTS preloading should ensure that site operators understand the long-term consequences of preloading before they turn it on for a given domain. They should also be informed that they need to meet additional requirements and submit their site to hstspreload.org to ensure that it is successfully preloaded (i.e. to get the full protection of the intended configuration).

The WordPress container image used by the 'WordPress on App Service' marketplace item does currently enable HSTS by default. If someone doesn't notice this, they can get really caught of guard, since now their domain and (internal) subdomains require https which browsers will remember for 1 year.

Enabling HSTS by default is maybe okay, but I don't think it should include subdomains and enable preloading, since that can have a huge impact.

$ docker run --rm --entrypoint /bin/sh mcr.microsoft.com/appsvc/wordpress-alpine-php -c 'grep -i strict-transport-security /etc/nginx/co
nf.d/spec-settings.conf'
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

At the very least this should be documented somewhere and preferably, as the hstspreload site suggests, it should be opt-in.

We noticed this thankfully at our company, and added this command to our /home/dev/startup.sh script:

sed -i '
/Strict-Transport-Security/d
' /etc/nginx/conf.d/spec-settings.conf

Azure / wordpress-linux-appservice

HSTS Preloading Should Be Opt-In #137