Setting HSTS at WordPress domains

[JavierCasares]

Should WordPress.org and all subdomains and other sites support HSTS by default?

Context around HTTP Strict Transport Security (HSTS)

RFC 6797 / ​https://datatracker.ietf.org/doc/html/rfc6797

This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.

Browser support

​https://caniuse.com/stricttransportsecurity

All major browser support this protocol.

Security improvement

​https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

​https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html

Checking it

​https://hstspreload.org/?domain=wordpress.org

Example

For nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

Notes

When applying HSTS, HTTP to HTTPS redirects must be done in an orderly fashion.

First, the hostname itself must be converted from HTTP to HTTPS, and then the hostname must be changed to the canonical.

In the case of the "www", it would be something like this:

server {
  listen 80;
  listen [::]:80;
  server_name wordpress.org;
  return 301 https://wordpress.org$request_uri;
  access_log off;
}
server {
  listen 80;
  listen [::]:80;
  server_name www.wordpress.org;
  return 301 https://www.wordpress.org$request_uri;
  access_log off;
}

And then, analyze if the hostname is the correct one and make the corresponding redirections, but already in HTTPS.

[jonoaldersonwp]

I'd be strongly in favour of this from an SEO and performance perspective.

[dd32]

Just noting that we've had this running on the main WordPress.org domain since early 2015, with a short timeout:

$ curl -Is https://wordpress.org/ | grep ^Strict
Strict-Transport-Security: max-age=360

This wasn't applied to other resources, as at the time we weren't sure if it would have any downsides or cause problems. That's also the reason for the low timeout.

There's no reason why we can't expand where this is set, although we'd probably keep it off api.wordpress.org which is deliberately accessible over HTTP for older WordPress installations (although, they wouldn't respect the header anyway. But it's more to be clear that it is intentionally available over HTTP).