How does HSTS handle mixed content?
How does HSTS handle mixed content?
I've just checked with the SSL Server Test if I implemented the SSL certificate on my server correctly. I got a grade A in their ranking but you can get an A+ if you have activated HSTS. After some seaching I found out that Google might treat HSTS as a ranking factor. So it seems to be relevant in terms of SEO. Before implementing HSTS I've got some questions.
Question 1
What happens if some external javascripts load for example an image over http (instead of https) on my site? Will HSTS prevent the whole page from loading or only block the specific "insecure" content?
Question 2
At the moment (without HSTS) I get a "mixed content" warning if resources are loaded via http. Does "mixed content" actually exists if HSTS is activated?
No, I'm not confusing those technologies. I've just no idea how HSTS works.
– Sr. Schneider
Aug 20 at 16:02
3 Answers
3
HSTS doesn't try to handle mixed content at all: it just controls whether the browser should perform an internal 307 redirect to HTTPS whenever it tries to load HTTP URLs, or not. The mixed content warning is a feature of the browser, and all the current browsers do it (Mozilla Firefox 23+, Google Chrome 21+, Internet Explorer 10+, Edge from the beginning...). The mixed content warning blocks e.g. <script> and <iframe>, but not <img>.
307
<script>
<iframe>
<img>
The mixed content warning on all the browsers mentioned is checked before loading any content at all, i.e. before HSTS redirects, too. This seems only natural, and is also easy to test. By default, all external images are loaded even using plain HTTP, and a mixed content warning is given only for scripts and iframes.
HSTS only changes the situation where an image from an HSTS enabled domain is loaded using plain HTTP, and 307 Internal Redirect is performed. Worth noting: this is a situation with no mixed content warnings involved.
307 Internal Redirect
Therefore, HSTS does not work as a quick fix for the mixed content problem:
http://
As a side note, if you are looking for a way to "upgrade" http requests to https, you may find some benefit from a content security policy (CSP), specifically the
upgrade-insecure-requests attribute. You can read about it here developer.mozilla.org/en-US/docs/Web/HTTP/Headers/…. It appears to work with chrome and firefox at this time.– David Goate
Aug 21 at 16:16
upgrade-insecure-requests
I think the answer to this would depend on whether the scripts you refer to are hosted on the domain for which HSTS is enabled.
E.g. if you serve your content from mydomain.com and enable HSTS for this domain (and possibly subdomains too) but the script(s) and other mixed content you refer to are served from otherdomain.com which does not enable HSTS then mixed content is possible and the browser will still warn about this.
mydomain.com
otherdomain.com
What HSTS will stop (and will help fix mixed content for) is resources linked to via HTTP on the same domain - and perhaps subdomain depending on your config - as these will be "upgraded" to HTTPS automatically.
And what about scripts from other domains? They'll be blocked?
– Sr. Schneider
Aug 20 at 8:22
No, I believe that HSTS applies to the domain that you apply the header to (and optionally the subdomains too). If you import a script from another domain which doesn't use HSTS and you do so via HTTP rather than HTTPS then the script isn't blocked due to HSTS (it might be blocked for other unrelated reasons like mixed content or CORS etc). In all likelihood, if you have a domain on HSTS and import resources via http from non hsts domains you'll get mixed content warnings.
– David Goate
Aug 20 at 9:24
This is by design: if HSTS is working, it'll retrieve the right image (the checkmark over HTTPS), and, if not, an X mark over HTTP.
Hopefully browsers will stop presenting mixed content warnings for content upgraded to HTTPS via HSTS. :)
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
It seems to me you may be confusing HSTS with CSP. Both are optional HTTPS-related security features controlled by specific HTTP(S) response headers, and they can both be used (in different cases) to automatically upgrade insecure HTTP requests to HTTPS, but that's about where the similarity ends.
– Ilmari Karonen
Aug 20 at 13:42