[lstamour]

Yep: HSTS only applies to your site, while upgrade-insecure-requests applies to every resource your site loads, even on third-party domains? Meanwhile, upgrade-insecure-requests does not replace HSTS because it doesn't help secure links from offsite or direct entry, which HSTS solves especially with preloading. Monitoring CSP headers and actually fixing bugs would help fix things in browsers that don't support upgrade-insecure-requests.

[ahochhaus]

Thanks for the clarification. I did not realize that `upgrade-insecure-requests` applies cross origin. If you do not load any insecure content is setting HSTS and `block-all-mixed-content` the best strategy?

[lstamour]

As pointed out by Microsoft earlier today, MDN is one of the best resources on this sort of thing. Here they write:

> The upgrade-insecure-requests directive is evaluated before block-all-mixed-content and If the former is set, the latter is effectively a no-op. It is recommended to set one directive or the other – not both.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co... and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

Yes they are similar, and you have to watch which one you set -- but you can also achieve a similar effect at a more granular level using CSP as also indicated in MDN. These rules are equivalent to saying `default-src https:` in the CSP rule.

In fact, the best option is individual CSP directives which can get more granular than the `https:` scheme alone, because you can then specify which trusted third-party domains (if any) are allowed to load resources on your pages and conditions (like nonces) for running script tags, data URIs, etc. After all, your secure third-party resources could still have servers compromised and they might then send malicious assets over SSL to your unsuspecting users' browsers.

CSP, if trusted enough to set it to block instead of just report (though you can run both modes at the same time), is one of the best defence-in-depth ways to protect your page from attack, right up there with HttpOnly and Secure flags on cookies. https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Se...

If you're looking for checklists, have a look at https://wiki.mozilla.org/Security/Guidelines/Web_Security and https://blog.appcanary.com/2017/http-security-headers.html though remember no checklist is going to deliver bulletproof security on its own (you'll have to inspect your app and environment for flaws, implement monitoring tools, etc.), and blindly implementing security headers or features without knowing what they do can obviously break your app. (Again, monitoring your app can help.)