HSTS restricts the connection to be always HTTPS if deployed by any domain, however for it to be applied to sub-domains the 'includeSubDomain' attribute is needed. Why doesn't the policy itself make it mandatory to include all subdomains? For what reasons/restrictions is the flag asked to be set?
Why does HSTS not automatically apply to subdomains to enhance security? For what reason would someone not want HSTS on every subdomain?
Wouldn't that require certificates for each sub domain or a wildcard certificate? You cannot use HSTS with self signed certificates. This would lead to significantly higher deployment costs and thus hurt the adoption of HSTS.– bot47Oct 29, 2016 at 8:58
By extension, for what reason would someone not want HSTS everywhere?– Hagen von EitzenApr 10, 2020 at 17:49
Subdomains can often be used for different purposes, and as a result they can be using different web applications possibly hosted on different equipment.
Not every website on every subdomain needs to follow the policy of the domain, it can even be the case that sites on subdomains do not support HTTPS due to lack of support in the application and/or not having a SSL certificate.
So automatically enforcing a policy on the main domain could possibly break things for subdomains.
1+1 - if HSTS was subdomain mandatory, many orgs could not use it if they have an Active Directory domain which is a subdomain off their public domain. Which is exactly what Microsoft publish as best practice. Oct 28, 2016 at 15:18
@MarkHenderson why would that affect AD? Oct 28, 2016 at 18:18
1@RobertGrant say you own
example.comand you deploy your AD on
ad.example.com- now you set up a web service at
service.ad.example.com- if HSTS was forced on for subdomains, it would be forced on for
service.ad.example.comwhich you may not want, or may not even be supported for that application/appliance. Oct 28, 2016 at 19:03
Something else that comes to my mind is to serve cookie-less static content. This is usually done by having your site
example.comfetch images on
http://images.example.com/, instead of
httpS://example.com/images/, which can improve on speed and parallel download of files. Oct 28, 2016 at 22:21
3@IsmaelMiguel having images over HTTP in a HTTPS page is a bad idea. I think most browsers would at least give a mixed-content warning. Oct 28, 2016 at 22:36
It's best to let the site owner decide whether subdomains are affected, just as the site owner decides whether to use HSTS at all. The extra flexibility could help improve HSTS adoption by reducing compatibility obstacles.
Some of the subdomain services may not have an HTTPS server installed yet. There are a few cases where it's not important security-wise to have HTTPS on certain subdomains.
That answers why
includeSubDomain is not mandatory.
One could still ask why it is not the default:
For this I would like to point out that HSTS cannot be undone except by asking your visitors to clear cache in their own browser. Chances are your visitors will not do this.
So, if you accidentally applied HSTS to more than you intended to, that (sub)domain goes down permanently for those visitors until they switch devices or browsers, clear cache on the browser, or the site owner installs an HTTPS server. (which might be technically difficult on some legacy services)
5Chances are at that point you have no easy way of contacting the visitors of your site in the first place.– userOct 28, 2016 at 14:07
6"Some of the subdomain services may not have an HTTPS server installed yet." -- An in fact, may not even be under your control. It's fairly common to add DNS records for subdomains for SaaS apps like a CRM, recruiting software, etc. Oct 28, 2016 at 19:26
My best example on why this would be bad, is webhosting. Imagine a webhost, lets say somecheapwebhostingexample.com has HSTS and even a payment page. And then they don't have wildcard certificates or anything like that.
Then a customer signs up as customer1.somecheapwebhostingexample.com . Its obvious its a bad example to deploy subdomains per default here.
There are other examples where theres multiple subdomains, but no certificate available for them all.