Help adding includeSubDomains to the Strict-Transport-Security header

Installation Hosting
1

A client used a helpful security scanner and now believes that the Strict-Transport-Security header should include ‘includeSubdomains’.

I’ve added both of these to the app.yml:


  after_ssl:
    - replace:
        filename: /etc/nginx/conf.d/outlets/server/20-https.conf
        from: "max-age=31536000;"
        to:  "max-age=31536000; includeSubDomains;"
    - replace:
        filename: /etc/nginx/conf.d/outlets/discourse/20-https.conf
        from: "max-age=31536000;"
        to:  "max-age=31536000; includeSubDomains;"

- exec: sed -i "s/add_header Strict-Transport-Security 'max-age=31536000';/add_header Strict-Transport-Security \"max-age=31536000; includeSubDomains\" always;/" /etc/nginx/conf.d/outlets/discourse/20-https.conf /etc/nginx/conf.d/outlets/server/20-https.conf

Neither seems to work. Running the sed command in the second on inside the container works and after restarting nginx, does what’s requested.

I don’t understand why it won’t work.

Also, this used to be in the template, but it seems like it was removed in 2014, but some recent posts include headers that show the includeSubdomains in there.

I’m stumped

1 Like
2

Hmm.. you don’t seem to be getting an answer here. Does this topic belong in Dev or Installation > Hosting? :thinking:

1 Like
3

Well,l I moved it there, but the initial issue is that someone claimed that not setting includeSubDomains was a security issue.

I’d love it if someone who knew and cared about whether having IncludeSubDomains in the the STS header was important could address the issue so perhaps I could tell this person that hundreds of thousands of other sites disagree and that perhaps the script that someone ran to find these “security flaws” is wrong.

So maybe I should rename this “missing includeSubDomains in STS header considered harmful”

2 Likes
5

I would call it a configuration choice instead.

Is the forum on an apex domain or not?

I always tell people that we are very cautious of setting headers that affect other hostnames on their domain, and if they want to have HSTS on those, they should set the headers on those respective hosts instead.

The only valid reason I can think of is they cannot do that, e.g. when the forum is on an apex domain and the client is not able to control the HSTS headers on other externally hosted hosts, e.g. they have hostedshopify.example.com as well. Then they basically come to you because you’re the path of least resistance :slight_smile:

2 Likes
6

It is not.

That’s what I think I thought, though I wasn’t able to articulate it.

Thanks. I’ll tell them that since it’s not the Apex domain it’s Best Practice to have each host enforce its own rules.

Thanks so very much. This is a big help. At least now am pretty sure thatI understand.

2 Likes