HSTS in Nginx: should the Strict-Transport-Security header be added in subdomain server blocks too?

You are correct that it's better to have the HSTS Strict-Transport-Security header everywhere you need it to make sure a client gets it even if sub.example.com is accessed before example.com or if the cached HSTS information has expired.

The includeSubDomains flag affects all subdomains of where it's present. This means that includeSubDomains on sub.example.com takes effect on *.sub.example.com instead of *.example.com. (This is only natural as it would be bad if e.g. example.co.uk could affect *.co.uk.)

• If you don't use any sub.sub.example.com you could leave the Strict-Transport-Security header of your subdomains without this flag.

• subA.example.com can't protect subB.example.com.

Correct. The includeSubdomains option is used to enforce https on all resources linked inside an html page served by the current domain.

Quoting https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/ :

For example, the HTML response for https://www.example.com can include a request to a resource from https://example.com, to make sure that HSTS is set for all subdomains of example.com.

Also beware that if you add an add_header directive inside a location { } block, you also need to redefine add_header Strict-Transport-Security ... inside that block. Quoting again:

NGINX configuration blocks inherit add_header directives from their enclosing blocks, so you just need to place the add_header directive in the top‑level server block. There’s one important exception: if a block includes an add_header directive itself, it does not inherit headers from enclosing blocks, and you need to redeclare all add_header directives: