10 ms·

HTTP Security Headers – A Complete Guide

709 points by BCharlie 7y ago

spectre256 7y ago
It's definitely worth repeating the warning that, while very useful, Strict-Transport-Security should be deployed with special care! While the author's example of `max-age=3600` means there's only an hour of potential problems, enabling Strict-Transport-Security has the potential to prevent people from accessing your site if for whatever reason you are no longer able to serve HTTPS traffic. Considering another common setting is to enable HSTS for a year, its worth enabling only deliberately and with some thought.
- sjwright 7y ago
  Not being able to serve HTTPS is not a real concern. It seems possible but in reality it simply won’t happen. If it ever does break, you fix it, you don’t change protocols. Once you go HTTPS you’re all in regardless whether or not you’ve set HSTS headers. Let’s say your HTTPS certificate fails and you can’t get it replaced. So what, you’re going to temporarily move back to HTTP for a few days? Not going to happen! Everyone has already bookmarked/linked/shared/crawled your HTTPS URLs. There is no automated way to downgrade people to HTTP, so only the geeks who would even think to try removing the “s” will be able to visit. And most geeks won’t even do that because we’ve probably never encountered a situation where that has ever helped.
  - SquareWheel 7y ago
    It happened to me. I served my site over TLS and used HSTS. Hosting got expensive, so I rebuilt my site on Github Pages and hosted there. It was another year and a half before they rolled out HTTPS for custom domains. In that case, old visitors were rejected due to the policy. I wish I had set a lower duration.
    - sjwright 7y ago
      > old visitors were rejected due to the policy Also because their links and bookmarks would have all failed.
      - shawnz 7y ago
        But HSTS also blocks the workaround of "just Google it and find the page again"
        LinuxBender 7y ago
        You can use the webmaster tools on Google to fix the indexing. It takes a few days, but worth the effort.
        MichaelApproved 7y ago
        The issue is that the browser won't let you visit the insecure URL, regardless of how you get to it. It won't work because the HSTS setting the visitor got months ago told it not to.
        LinuxBender 7y ago
        That is exactly what I am talking about. In the webmaster tools, you want to get google to remove all references to the non https versions. Ensure https is up on all URL's, then use their tools to re-index everything and remove all references to http:// http:// Are you saying you can't set up https on some of your URL's?
        shawnz 7y ago
        The argument here is that enabling HSTS can be dangerous because if you enable it and then later become unable to serve HTTPS for some reason, you will have no way of turning it off. Even if you get your clients to manually edit their bookmarks to use HTTP again, their browsers will just rewrite the url to HTTPS anyway. There's no issue with switching FROM HTTP to HTTPS: that's easy, just redirect them. The issue is if you have to switch back.
- BCharlie 7y ago
  I think it's a good point which is why I set the time low, even though many other resources set it to a week or longer. I just don't like very long cache times for anything that can break, so that site owners have a little more flexibility in case something goes wrong down the line.
- Someone1234 7y ago
  It is a good point. I would like to add that a lot of web-apps break if they aren't served over HTTPS regardless, due to the Secure flag being set on cookies. For example if we run ours in HTTP (even for development) it will successfully set the cookie (+Secure +HttpOnly) but cannot read the cookie back and you get stuck on the login page indefinitely. So we just set ours to a year, and consider HTTPS to be a mission critical tier component. It goes down the site is simply "down." HSTS is kind of the "secret sauce" that gives developers coverage to mandate Secure cookies only. Before then we'd get caught in "what if" bikeshedding[0]. [0] https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding
- zaarn 7y ago
  I set HSTS to 10 years. My infrastructure isn't even capable of serving HTTP other than for LetsEncrypt certs. An outage on HTTPS is a full outage. Most of my sites handle user data in some way, so HTTPS is mandatory anyway, as per my interpretation of the GDPR.
- pimterry 7y ago
  The only risk is if you've served HTTPS traffic properly with HSTS headers to users, and then your server is later unable to correctly handle HTTPS traffic. Note that HSTS headers on a non-HTTPS response are ignored. Whilst there's cases where you might fail to serve HTTPS traffic temporarily (i.e. if your cert expires and you don't handle it) almost all HTTPS problems are quick fixes, and are probably your #1 priority regardless of HSTS. If your HTTPS setup is broken and your application has any real security concerns at all then it's arguably better to be inaccessible, rather than quietly allow insecure traffic in the meantime, exposing all your users' traffic. I don't know many good reasons you'd suddenly want to go from HTTPS back to only supporting plain HTTP either. I just can't see any realistic scenarios where HSTS causes you extra problems.
- tialaramex 7y ago
  I don't get people who worry about _feature_ pinning like this. I imagine them looking at a business continuity plan and being aghast - why are we spending money to manage the risk from a wildfire in California overwhelming our site there, yet we haven't spent ten times as much on a zombie werewolf defence grid or to protect against winged bears? HSTS defends against a real problem that actually happens, like those Californian wildfires, whereas "whatever reason you are no longer able to serve HTTPS traffic" is a fantasy like the winged bears that you don't need to concern yourself with.
- txcwpalpha 7y ago
  Unless your site is nothing but a dumb billboard serving nothing but static assets (and maybe even then...), the inability to serve HTTPS traffic should be considered a breaking issue and you shouldn't be serving anything until your HTTPS is restored. "Reduced security" is not a valid fallback option. That might not be something that a company's management team wants to hear, but indicating to your users that falling back to insecure HTTP is just something that happens sometimes and they should continue using your site is one of the worst things you can possibly do in terms of security.
  - bityard 7y ago
    Here's a real example of how HSTS can break a site: My personal, non-public wiki is secured by HTTPS with a certificate valid for 5 years. I thought it would be neat to enable HSTS for it because what could go wrong? Well, just last week the HTTPS certificate expired in the middle of the day. I had about a half days' worth of work typed up into the browser's text field and when I clicked "submit", all of my work vanished and Firefox only showed a page stating that the certificate was invalid and that nothing could be done about it. I clicked the back button, same thing. Forward button, same thing. A half-days worth of work vanished into thin air. Is this my fault for letting the certificate expire? Absolutely. Should I have used letsencrypt so I didn't have to worry about it. Sure. Should I be using a notes system that doesn't throw away my work when there's a problem saving it? Definitely. I don't deny that there's lots that I could have done to prevent this from being a problem and lots that I need to fix in the future. But it does point out that if you use HSTS, you have to be _really_ sure that _all_ your ducks are in a row or it _will_ come back to bite you eventually.
    - ehPReth 7y ago
      Curious: Wouldn’t you be singing the same tune if the browser/system crashed? Or the database backend for the wiki went down? Or.. I thought the general way was to automatically save any progress in localstorage/etc ready to be retrieved if needed once the problem is fixed?
      - 7y ago
- ehPReth 7y ago
  Speaking of HSTS.. does anyone here know if Firebase Hosting (Google Cloud) plans to support custom HSTS headers with custom domains? I can’t add things like includesubdomains or preload at present unfortunately
- mtgx 7y ago
  > if for whatever reason you are no longer able to serve HTTPS traffic Isn't that how it should work? Would you rather use Gmail over HTTP if its HTTPS stopped working? Besides, just supporting HTTP fallback means you're much more vulnerable to downgrade attacks -- it's the first thing attackers will attempt to use.
- barathvutukuri 7y ago
  HSTS Preload is also nice. Common HSTS Preload configuration and opt-in link. https://hstspreload.org/ https://hstspreload.org/
Avamander 7y ago
Instead of X-Frame-Options one should use CSP's frame-ancestors option, it has wider support among modern browsers. But CSP deserves more than one paragraph in general. He also missed Expect-Staple and Expect-CT, in addition to that, most of security headers have the option to specify an URI where failures are sent, very important in production environments.
- BCharlie 7y ago
  That is true! I do set frame-ancestors in the sample CSP for this reason. I could probably do a dedicated post on CSP to do it justice, but don't want to overwhelm anyone who just wants to start setting headers. One good reason to set both options, as I mention in the post, is that scanners who rate site security posture may penalize site owners who don't set both - no harm in doing it that I know of.
  - Jach 7y ago
    Nitpicking as I like to see practical awareness posts like yours spread: you should link to the CSP spec (v3) as the official site. https://content-security-policy.com/ https://content-security-policy.com/ is useful to get started but is out of date and Foundeo isn't authoritative. For a "complete" guide (maybe "comprehensive starter guide"?) I'd at least add a note in the x-frame-options section that it's been superseded by CSP and only needed if you must support IE (or I guess please a tool), and if you have interesting frame requirements (i.e. more than one allowed ancestor but not all) you're going to have to use a hack to support that with the old header. Another interesting callout is that most of the CSP directives can be specified by a meta tag in the markup. Not only is this handy for quick serverless testing but can become necessary if you end up routing through something (like some CDNs) that has a max overall headers limit... CSP headers can get pretty big if you don't just bail out with a wildcard. Definitely agree CSP can have its own post. It's complicated and still evolving with new spec versions. I recently learned about chrome's feature-policy header proposal, which to me is like more granular script-src policies, so I wouldn't be surprised if some future CSP version just absorbs it...
    - 7y ago
Grollicus 7y ago
Should mention for Access-Control-Allow-Origin that the default value is the safe default and setting this header weakens site security.
- BCharlie 7y ago
  Great point! I added a sentence to say that the default is all that's needed.
jakejarvis 7y ago
Great overview. If anyone's interested, I wrote a guide a while ago on adding these headers via Cloudflare Workers, which can be helpful if you're hosting a static site on S3, GitHub Pages, etc. where you can't add these headers directly: https://jarv.is/notes/security-headers-cloudflare-workers/ https://jarv.is/notes/security-headers-cloudflare-workers/
undecidabot 7y ago
Nice list. You might want to consider setting a "Referrer-Policy"[1] for sites with URLs that you'd prefer not to leak. Also, for "Set-Cookie", the relatively new "SameSite"[2] directive would be a good addition for most sites. Oh, and for CSP, check Google's evaluator out[3]. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re... [2] https://www.owasp.org/index.php/SameSite https://www.owasp.org/index.php/SameSite [3] https://csp-evaluator.withgoogle.com https://csp-evaluator.withgoogle.com
- will4274 7y ago
  Referrer-Policy is nice, but browsers should just default to strict-origin-when-cross-origin and end the mess.
deftnerd 7y ago
This is a good basic overview of the basic headers, but I suggest spending some time on Scott Helme's blog. He runs securityheaders.io, a free service that scans your site, and assigns it a letter grade based on what headers and configurations you've applied. For instance, his explanation of Content Security Policy headers is much more detailed than in the OP's link. https://scotthelme.co.uk/content-security-policy-an-introduction/ https://scotthelme.co.uk/content-security-policy-an-introduc...
- el_duderino 7y ago
  securityheaders.io is now securityheaders.com https://scotthelme.co.uk/security-headers-is-changing-domain-and-branding/ https://scotthelme.co.uk/security-headers-is-changing-domain...
- t34543 7y ago
  Mozilla Observatory does the same thing. https://observatory.mozilla.org/ https://observatory.mozilla.org/
joecot 7y ago
I'm a little confused by the examples for Access-Control-Allow-Origin: > Access-Control-Allow-Origin: http://www.one.site.com http://www.one.site.com > Access-Control-Allow-Origin: http://www.two.site.com http://www.two.site.com And in the examples setting both. Because in my experience you cannot set multiple [1]. Lots of people instead set it to * which is both bad and restricts use of other request options (such as withCredentials). It looks like the current working solution is to use regexes to return the right domain [2], but I'm currently having trouble getting that to work, so if there's some better solution that works for people I'd love to hear it. 1. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Error... 2. https://stackoverflow.com/questions/1653308/access-control-allow-origin-multiple-origin-domains https://stackoverflow.com/questions/1653308/access-control-a...
- jrockway 7y ago
  I think the problem that people are running into with CORS is that their webserver was created before CORS was a thing, so it's tough to configure it correctly. What you want to do is if you allow the provided Origin, echo it back in Access-Control-Allow-Origin. Envoy has a plugin to do this (envoy.cors), allowing you to configure allowed origins the way people want (["*.example.com", "foo.com"]) and then emitting the right headers when a request comes in. It also emits statistics on how many requests were allowed or denied, so you can monitor that your rules are working correctly. If you are using something else, I recommend just having your web application do the logic and supply the right headers. (You should also be prepared to handle an OPTIONS request for CORS preflight.)
  - joecot 7y ago
    Sure, I wish web servers had better options for this. If you're trying to do it on the web server level it seems like the current solution is a regex with your list of approved origins vs the origin header, and then setting Access-Control-Allow-Origin to the matching one. But the current examples, showing just setting the header multiple times, will lead devs down the garden path. Unless I'm missing something, which I very much hope I am.
the_common_man 7y ago
X-frame-options is obsolete. Most browsers complain loudly on the console or ignore the header. Use csp instead
- floatingatoll 7y ago
  For those wondering, CSP ‘frame-ancestors’ if I remember correctly.
  - user5994461 7y ago
    It's a shame browsers are breaking the X-Frame-Options. It was an easy option to force with load balancers or any intermediate server. Frames should always be blocked on the open internet. The content security policy can't be adjusted easily. It screws with applications and frameworks that use it for any of the twenty other options it covers.
    - floatingatoll 7y ago
      Why? It’s been deprecated for years and years. You don’t have to set any of the other 20 CSP options to set CSP:frame-ancestors. There’s no reason to avoid it except taking a completionist approach to CSP headers (“we have to set all possible CSP attributes for maximum security in a single go on our first try”) which I strongly discourage.
      - user5994461 7y ago
        You can't just do a "set header Content-Security-Policy frame-ancestors none" on all traffic. This is gonna break anything using CSP for any of the 20 settings it provides.
        floatingatoll 7y ago
        Correct. You would be expected to merge it into any CSP headers used by your app, either using (in your Apache scenario) If/Else and Header modify or by modifying your application where appropriate. While XFO is simpler to overwrite on a global basis, it’s imprecise and doesn’t permit “allow certain sites to frame, deny all others” and is likely to become fully unsupported whenever any CSP policy is defined, given its deprecated status. Taking the XFO way out will only help you short-term at best.
mitchtbaum 7y ago
* [Signing HTTP Messages](https://tools.ietf.org/id/draft-cavage-http-signatures-09.html https://tools.ietf.org/id/draft-cavage-http-signatures-09.ht...) * [HTTP Signatures](https://tools.ietf.org/id/draft-cavage-http-signatures-01.html https://tools.ietf.org/id/draft-cavage-http-signatures-01.ht...) * [draft-cavage-http-signatures-10 - Signing HTTP Messages](https://tools.ietf.org/html/draft-cavage-http-signatures-10 https://tools.ietf.org/html/draft-cavage-http-signatures-10) * [https://www.rfc-editor.org/rfc/rfc4686.txt](https://www.rfc-editor.org/rfc/rfc4686.txt) https://www.rfc-editor.org/rfc/rfc4686.txt](https://www.rfc-... * [https://www.rfc-editor.org/rfc/rfc3335.txt](https://www.rfc-editor.org/rfc/rfc3335.txt) https://www.rfc-editor.org/rfc/rfc3335.txt](https://www.rfc-...
cujanovic 7y ago
https://www.netsparker.com/whitepaper-http-security-headers/ https://www.netsparker.com/whitepaper-http-security-headers/
- kureikain 7y ago
  This is such a great and completed guide. Lots of headers with example and explanations. Have been looking for it. I will include in in my newsletter[0] next monday if you don't mind. --- [0]: https://betterdev.link https://betterdev.link
yyyk 7y ago
The X-XSS-Protection header recommendation is a Zombie recommendation which is at best outdated and at worst harmful. Its origins are based on old IE bugs but it introduces worse issues. IMHO, the best value for X-XSS-Protection is either 0 (disabling it completely like Facebook does) or not providing the value at all and just letting the client browser use its default. Why? First, XSS 'protection' is about to not be implemented by most browsers. Google has decide to deprecate Chrome's XSS Auditor[0], and stop supporting XSS 'protection'. Microsoft has already removed its XSS filter from Edge[1]. Mozilla has never bothered to support it in Firefox. So most leading net companies already think it doesn't work. Safari of course supports the much stronger CSP. So it's only possibly useful on IE - if you don't support IE, might as well save the bytes. Second, XSS 'protection' protects less than one might think. In all implementing browsers, it has always been implemented as part of the HTML parser, making it useless against DOM-based attacks (and strictly inferior to CSP)[2]. Worse, the XSS 'protection' can be used to create security flaws. IE's default is to detect XSS and try to filter it out, this has been known to be buggy to the point of creating XSS on safe pages[3], which is why the typical recommendation has been the block behaviour. But blocking has been itself exploited in the past[4], and has side-channel leaks that even Google considers too difficult to catch[0] to the point of preferring to remove XSS 'protection' altogether. Blocking has an obvious social exploitation which can create attacks or make attacks more serious.[5] In short, the best idea is to get rid of browsers' XSS 'protection' ASAP in favour of CSP, preferably by having all browsers deprecate it. This is happening anyway, so might as well save the bytes. But if you do provide the header, I suggest disable XSS 'protection' altogether. [0] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TuYw-EZhO9g/blGViehIAwAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d... [1] https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/17723/ https://developer.microsoft.com/en-us/microsoft-edge/platfor... [2] e.g. https://github.com/WebKit/webkit/blob/d70365e65de64b8f6eaf1ff5bf1a901765e47923/Source/WebCore/html/parser/XSSAuditor.cpp https://github.com/WebKit/webkit/blob/d70365e65de64b8f6eaf1f... [3] CVE-2014-6328, CVE-2015-6164, CVE-2016-3212.. [4] https://portswigger.net/blog/abusing-chromes-xss-auditor-to-steal-tokens https://portswigger.net/blog/abusing-chromes-xss-auditor-to-... [5] Assume that an attacker has enough access to normally allow XSS. If he does not, the filter is useless. If he does, the attacker can by definition trigger the filter. So trigger the filter, make a webpage be blocked, and call the affected user as "support". From there the exploitation is obvious, and can be much worse than mere XSS. Now, remember that all those XSS filters in all likelihood have false positives, that may not be blocked by other defences because they're not attacks. So It's quite possible the filter introduces a social attack that wouldn't be possible otherwise! Hattip: https://frederik-braun.com/xssauditor-bad.html https://frederik-braun.com/xssauditor-bad.html which gave me even more reasons to think browsers' XSS 'protection' is awful. I didn't know about [2] before reading his entry.
dalf 7y ago
There is the Feature-Policy header too : allow and deny the use of browser features in its own frame. I've seen this header on a bank website. Example : Feature-Policy: accelerometer 'none'; autoplay 'none'; camera 'none'; fullscreen 'none' Documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Po...
wheresvic1 7y ago
For Node.js servers running on express, check out helmet[1] which adds a lot of these headers for you :) [1] https://www.npmjs.com/package/helmet https://www.npmjs.com/package/helmet
hcheung 7y ago
The nginx header directives are all not in correct syntax with the extra ":", and for those directives with multiple values, it should be wrapped within a "" (such as "1; mode=block"), here is the correct settings: ## General Security Headers add_header X-XSS-Protection "1; mode=block"; add_header X-Frame-Options deny; add_header X-Content-Type-Options nosniff; add_header Strict-Transport-Security "max-age=3600; includeSubDomains";

709 points by BCharlie 7y ago

It's definitely worth repeating the warning that, while very useful, Strict-Transport-Security should be deployed with special care! While the author's example of `max-age=3600` means there's only an hour of potential problems, enabling Strict-Transport-Security has the potential to prevent people from accessing your site if for whatever reason you are no longer able to serve HTTPS traffic. Considering another common setting is to enable HSTS for a year, its worth enabling only deliberately and with some thought.

sjwright 7y ago
Not being able to serve HTTPS is not a real concern. It seems possible but in reality it simply won’t happen. If it ever does break, you fix it, you don’t change protocols. Once you go HTTPS you’re all in regardless whether or not you’ve set HSTS headers. Let’s say your HTTPS certificate fails and you can’t get it replaced. So what, you’re going to temporarily move back to HTTP for a few days? Not going to happen! Everyone has already bookmarked/linked/shared/crawled your HTTPS URLs. There is no automated way to downgrade people to HTTP, so only the geeks who would even think to try removing the “s” will be able to visit. And most geeks won’t even do that because we’ve probably never encountered a situation where that has ever helped.
- SquareWheel 7y ago
  It happened to me. I served my site over TLS and used HSTS. Hosting got expensive, so I rebuilt my site on Github Pages and hosted there. It was another year and a half before they rolled out HTTPS for custom domains. In that case, old visitors were rejected due to the policy. I wish I had set a lower duration.
  - sjwright 7y ago
    > old visitors were rejected due to the policy Also because their links and bookmarks would have all failed.
    - shawnz 7y ago
      But HSTS also blocks the workaround of "just Google it and find the page again"
      - LinuxBender 7y ago
        You can use the webmaster tools on Google to fix the indexing. It takes a few days, but worth the effort.
        MichaelApproved 7y ago
        The issue is that the browser won't let you visit the insecure URL, regardless of how you get to it. It won't work because the HSTS setting the visitor got months ago told it not to.
        LinuxBender 7y ago
        That is exactly what I am talking about. In the webmaster tools, you want to get google to remove all references to the non https versions. Ensure https is up on all URL's, then use their tools to re-index everything and remove all references to http:// http:// Are you saying you can't set up https on some of your URL's?
        shawnz 7y ago
        The argument here is that enabling HSTS can be dangerous because if you enable it and then later become unable to serve HTTPS for some reason, you will have no way of turning it off. Even if you get your clients to manually edit their bookmarks to use HTTP again, their browsers will just rewrite the url to HTTPS anyway. There's no issue with switching FROM HTTP to HTTPS: that's easy, just redirect them. The issue is if you have to switch back.
BCharlie 7y ago
I think it's a good point which is why I set the time low, even though many other resources set it to a week or longer. I just don't like very long cache times for anything that can break, so that site owners have a little more flexibility in case something goes wrong down the line.
Someone1234 7y ago
It is a good point. I would like to add that a lot of web-apps break if they aren't served over HTTPS regardless, due to the Secure flag being set on cookies. For example if we run ours in HTTP (even for development) it will successfully set the cookie (+Secure +HttpOnly) but cannot read the cookie back and you get stuck on the login page indefinitely. So we just set ours to a year, and consider HTTPS to be a mission critical tier component. It goes down the site is simply "down." HSTS is kind of the "secret sauce" that gives developers coverage to mandate Secure cookies only. Before then we'd get caught in "what if" bikeshedding[0]. [0] https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding
zaarn 7y ago
I set HSTS to 10 years. My infrastructure isn't even capable of serving HTTP other than for LetsEncrypt certs. An outage on HTTPS is a full outage. Most of my sites handle user data in some way, so HTTPS is mandatory anyway, as per my interpretation of the GDPR.
pimterry 7y ago
The only risk is if you've served HTTPS traffic properly with HSTS headers to users, and then your server is later unable to correctly handle HTTPS traffic. Note that HSTS headers on a non-HTTPS response are ignored. Whilst there's cases where you might fail to serve HTTPS traffic temporarily (i.e. if your cert expires and you don't handle it) almost all HTTPS problems are quick fixes, and are probably your #1 priority regardless of HSTS. If your HTTPS setup is broken and your application has any real security concerns at all then it's arguably better to be inaccessible, rather than quietly allow insecure traffic in the meantime, exposing all your users' traffic. I don't know many good reasons you'd suddenly want to go from HTTPS back to only supporting plain HTTP either. I just can't see any realistic scenarios where HSTS causes you extra problems.
tialaramex 7y ago
I don't get people who worry about _feature_ pinning like this. I imagine them looking at a business continuity plan and being aghast - why are we spending money to manage the risk from a wildfire in California overwhelming our site there, yet we haven't spent ten times as much on a zombie werewolf defence grid or to protect against winged bears? HSTS defends against a real problem that actually happens, like those Californian wildfires, whereas "whatever reason you are no longer able to serve HTTPS traffic" is a fantasy like the winged bears that you don't need to concern yourself with.
txcwpalpha 7y ago
Unless your site is nothing but a dumb billboard serving nothing but static assets (and maybe even then...), the inability to serve HTTPS traffic should be considered a breaking issue and you shouldn't be serving anything until your HTTPS is restored. "Reduced security" is not a valid fallback option. That might not be something that a company's management team wants to hear, but indicating to your users that falling back to insecure HTTP is just something that happens sometimes and they should continue using your site is one of the worst things you can possibly do in terms of security.
- bityard 7y ago
  Here's a real example of how HSTS can break a site: My personal, non-public wiki is secured by HTTPS with a certificate valid for 5 years. I thought it would be neat to enable HSTS for it because what could go wrong? Well, just last week the HTTPS certificate expired in the middle of the day. I had about a half days' worth of work typed up into the browser's text field and when I clicked "submit", all of my work vanished and Firefox only showed a page stating that the certificate was invalid and that nothing could be done about it. I clicked the back button, same thing. Forward button, same thing. A half-days worth of work vanished into thin air. Is this my fault for letting the certificate expire? Absolutely. Should I have used letsencrypt so I didn't have to worry about it. Sure. Should I be using a notes system that doesn't throw away my work when there's a problem saving it? Definitely. I don't deny that there's lots that I could have done to prevent this from being a problem and lots that I need to fix in the future. But it does point out that if you use HSTS, you have to be _really_ sure that _all_ your ducks are in a row or it _will_ come back to bite you eventually.
  - ehPReth 7y ago
    Curious: Wouldn’t you be singing the same tune if the browser/system crashed? Or the database backend for the wiki went down? Or.. I thought the general way was to automatically save any progress in localstorage/etc ready to be retrieved if needed once the problem is fixed?
    - 7y ago
ehPReth 7y ago
Speaking of HSTS.. does anyone here know if Firebase Hosting (Google Cloud) plans to support custom HSTS headers with custom domains? I can’t add things like includesubdomains or preload at present unfortunately
mtgx 7y ago
> if for whatever reason you are no longer able to serve HTTPS traffic Isn't that how it should work? Would you rather use Gmail over HTTP if its HTTPS stopped working? Besides, just supporting HTTP fallback means you're much more vulnerable to downgrade attacks -- it's the first thing attackers will attempt to use.
barathvutukuri 7y ago
HSTS Preload is also nice. Common HSTS Preload configuration and opt-in link. https://hstspreload.org/ https://hstspreload.org/

Avamander 7y ago

Instead of X-Frame-Options one should use CSP's frame-ancestors option, it has wider support among modern browsers. But CSP deserves more than one paragraph in general. He also missed Expect-Staple and Expect-CT, in addition to that, most of security headers have the option to specify an URI where failures are sent, very important in production environments.

BCharlie 7y ago
That is true! I do set frame-ancestors in the sample CSP for this reason. I could probably do a dedicated post on CSP to do it justice, but don't want to overwhelm anyone who just wants to start setting headers. One good reason to set both options, as I mention in the post, is that scanners who rate site security posture may penalize site owners who don't set both - no harm in doing it that I know of.
- Jach 7y ago
  Nitpicking as I like to see practical awareness posts like yours spread: you should link to the CSP spec (v3) as the official site. https://content-security-policy.com/ https://content-security-policy.com/ is useful to get started but is out of date and Foundeo isn't authoritative. For a "complete" guide (maybe "comprehensive starter guide"?) I'd at least add a note in the x-frame-options section that it's been superseded by CSP and only needed if you must support IE (or I guess please a tool), and if you have interesting frame requirements (i.e. more than one allowed ancestor but not all) you're going to have to use a hack to support that with the old header. Another interesting callout is that most of the CSP directives can be specified by a meta tag in the markup. Not only is this handy for quick serverless testing but can become necessary if you end up routing through something (like some CDNs) that has a max overall headers limit... CSP headers can get pretty big if you don't just bail out with a wildcard. Definitely agree CSP can have its own post. It's complicated and still evolving with new spec versions. I recently learned about chrome's feature-policy header proposal, which to me is like more granular script-src policies, so I wouldn't be surprised if some future CSP version just absorbs it...
  - 7y ago

Grollicus 7y ago

Should mention for Access-Control-Allow-Origin that the default value is the safe default and setting this header weakens site security.

BCharlie 7y ago
Great point! I added a sentence to say that the default is all that's needed.

jakejarvis 7y ago

Great overview. If anyone's interested, I wrote a guide a while ago on adding these headers via Cloudflare Workers, which can be helpful if you're hosting a static site on S3, GitHub Pages, etc. where you can't add these headers directly: https://jarv.is/notes/security-headers-cloudflare-workers/ https://jarv.is/notes/security-headers-cloudflare-workers/

undecidabot 7y ago

Nice list. You might want to consider setting a "Referrer-Policy"[1] for sites with URLs that you'd prefer not to leak. Also, for "Set-Cookie", the relatively new "SameSite"[2] directive would be a good addition for most sites. Oh, and for CSP, check Google's evaluator out[3]. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Re... [2] https://www.owasp.org/index.php/SameSite https://www.owasp.org/index.php/SameSite [3] https://csp-evaluator.withgoogle.com https://csp-evaluator.withgoogle.com

will4274 7y ago
Referrer-Policy is nice, but browsers should just default to strict-origin-when-cross-origin and end the mess.

deftnerd 7y ago

This is a good basic overview of the basic headers, but I suggest spending some time on Scott Helme's blog. He runs securityheaders.io, a free service that scans your site, and assigns it a letter grade based on what headers and configurations you've applied. For instance, his explanation of Content Security Policy headers is much more detailed than in the OP's link. https://scotthelme.co.uk/content-security-policy-an-introduction/ https://scotthelme.co.uk/content-security-policy-an-introduc...

el_duderino 7y ago
securityheaders.io is now securityheaders.com https://scotthelme.co.uk/security-headers-is-changing-domain-and-branding/ https://scotthelme.co.uk/security-headers-is-changing-domain...
t34543 7y ago
Mozilla Observatory does the same thing. https://observatory.mozilla.org/ https://observatory.mozilla.org/

joecot 7y ago

I'm a little confused by the examples for Access-Control-Allow-Origin: > Access-Control-Allow-Origin: http://www.one.site.com http://www.one.site.com > Access-Control-Allow-Origin: http://www.two.site.com http://www.two.site.com And in the examples setting both. Because in my experience you cannot set multiple [1]. Lots of people instead set it to * which is both bad and restricts use of other request options (such as withCredentials). It looks like the current working solution is to use regexes to return the right domain [2], but I'm currently having trouble getting that to work, so if there's some better solution that works for people I'd love to hear it. 1. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Error... 2. https://stackoverflow.com/questions/1653308/access-control-allow-origin-multiple-origin-domains https://stackoverflow.com/questions/1653308/access-control-a...

jrockway 7y ago
I think the problem that people are running into with CORS is that their webserver was created before CORS was a thing, so it's tough to configure it correctly. What you want to do is if you allow the provided Origin, echo it back in Access-Control-Allow-Origin. Envoy has a plugin to do this (envoy.cors), allowing you to configure allowed origins the way people want (["*.example.com", "foo.com"]) and then emitting the right headers when a request comes in. It also emits statistics on how many requests were allowed or denied, so you can monitor that your rules are working correctly. If you are using something else, I recommend just having your web application do the logic and supply the right headers. (You should also be prepared to handle an OPTIONS request for CORS preflight.)
- joecot 7y ago
  Sure, I wish web servers had better options for this. If you're trying to do it on the web server level it seems like the current solution is a regex with your list of approved origins vs the origin header, and then setting Access-Control-Allow-Origin to the matching one. But the current examples, showing just setting the header multiple times, will lead devs down the garden path. Unless I'm missing something, which I very much hope I am.

the_common_man 7y ago

X-frame-options is obsolete. Most browsers complain loudly on the console or ignore the header. Use csp instead

floatingatoll 7y ago
For those wondering, CSP ‘frame-ancestors’ if I remember correctly.
- user5994461 7y ago
  It's a shame browsers are breaking the X-Frame-Options. It was an easy option to force with load balancers or any intermediate server. Frames should always be blocked on the open internet. The content security policy can't be adjusted easily. It screws with applications and frameworks that use it for any of the twenty other options it covers.
  - floatingatoll 7y ago
    Why? It’s been deprecated for years and years. You don’t have to set any of the other 20 CSP options to set CSP:frame-ancestors. There’s no reason to avoid it except taking a completionist approach to CSP headers (“we have to set all possible CSP attributes for maximum security in a single go on our first try”) which I strongly discourage.
    - user5994461 7y ago
      You can't just do a "set header Content-Security-Policy frame-ancestors none" on all traffic. This is gonna break anything using CSP for any of the 20 settings it provides.
      - floatingatoll 7y ago
        Correct. You would be expected to merge it into any CSP headers used by your app, either using (in your Apache scenario) If/Else and Header modify or by modifying your application where appropriate. While XFO is simpler to overwrite on a global basis, it’s imprecise and doesn’t permit “allow certain sites to frame, deny all others” and is likely to become fully unsupported whenever any CSP policy is defined, given its deprecated status. Taking the XFO way out will only help you short-term at best.

mitchtbaum 7y ago

* [Signing HTTP Messages](https://tools.ietf.org/id/draft-cavage-http-signatures-09.html https://tools.ietf.org/id/draft-cavage-http-signatures-09.ht...) * [HTTP Signatures](https://tools.ietf.org/id/draft-cavage-http-signatures-01.html https://tools.ietf.org/id/draft-cavage-http-signatures-01.ht...) * [draft-cavage-http-signatures-10 - Signing HTTP Messages](https://tools.ietf.org/html/draft-cavage-http-signatures-10 https://tools.ietf.org/html/draft-cavage-http-signatures-10) * [https://www.rfc-editor.org/rfc/rfc4686.txt](https://www.rfc-editor.org/rfc/rfc4686.txt) https://www.rfc-editor.org/rfc/rfc4686.txt](https://www.rfc-... * [https://www.rfc-editor.org/rfc/rfc3335.txt](https://www.rfc-editor.org/rfc/rfc3335.txt) https://www.rfc-editor.org/rfc/rfc3335.txt](https://www.rfc-...

cujanovic 7y ago

https://www.netsparker.com/whitepaper-http-security-headers/ https://www.netsparker.com/whitepaper-http-security-headers/

kureikain 7y ago
This is such a great and completed guide. Lots of headers with example and explanations. Have been looking for it. I will include in in my newsletter[0] next monday if you don't mind. --- [0]: https://betterdev.link https://betterdev.link

yyyk 7y ago

The X-XSS-Protection header recommendation is a Zombie recommendation which is at best outdated and at worst harmful. Its origins are based on old IE bugs but it introduces worse issues. IMHO, the best value for X-XSS-Protection is either 0 (disabling it completely like Facebook does) or not providing the value at all and just letting the client browser use its default. Why? First, XSS 'protection' is about to not be implemented by most browsers. Google has decide to deprecate Chrome's XSS Auditor[0], and stop supporting XSS 'protection'. Microsoft has already removed its XSS filter from Edge[1]. Mozilla has never bothered to support it in Firefox. So most leading net companies already think it doesn't work. Safari of course supports the much stronger CSP. So it's only possibly useful on IE - if you don't support IE, might as well save the bytes. Second, XSS 'protection' protects less than one might think. In all implementing browsers, it has always been implemented as part of the HTML parser, making it useless against DOM-based attacks (and strictly inferior to CSP)[2]. Worse, the XSS 'protection' can be used to create security flaws. IE's default is to detect XSS and try to filter it out, this has been known to be buggy to the point of creating XSS on safe pages[3], which is why the typical recommendation has been the block behaviour. But blocking has been itself exploited in the past[4], and has side-channel leaks that even Google considers too difficult to catch[0] to the point of preferring to remove XSS 'protection' altogether. Blocking has an obvious social exploitation which can create attacks or make attacks more serious.[5] In short, the best idea is to get rid of browsers' XSS 'protection' ASAP in favour of CSP, preferably by having all browsers deprecate it. This is happening anyway, so might as well save the bytes. But if you do provide the header, I suggest disable XSS 'protection' altogether. [0] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TuYw-EZhO9g/blGViehIAwAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d... [1] https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/17723/ https://developer.microsoft.com/en-us/microsoft-edge/platfor... [2] e.g. https://github.com/WebKit/webkit/blob/d70365e65de64b8f6eaf1ff5bf1a901765e47923/Source/WebCore/html/parser/XSSAuditor.cpp https://github.com/WebKit/webkit/blob/d70365e65de64b8f6eaf1f... [3] CVE-2014-6328, CVE-2015-6164, CVE-2016-3212.. [4] https://portswigger.net/blog/abusing-chromes-xss-auditor-to-steal-tokens https://portswigger.net/blog/abusing-chromes-xss-auditor-to-... [5] Assume that an attacker has enough access to normally allow XSS. If he does not, the filter is useless. If he does, the attacker can by definition trigger the filter. So trigger the filter, make a webpage be blocked, and call the affected user as "support". From there the exploitation is obvious, and can be much worse than mere XSS. Now, remember that all those XSS filters in all likelihood have false positives, that may not be blocked by other defences because they're not attacks. So It's quite possible the filter introduces a social attack that wouldn't be possible otherwise! Hattip: https://frederik-braun.com/xssauditor-bad.html https://frederik-braun.com/xssauditor-bad.html which gave me even more reasons to think browsers' XSS 'protection' is awful. I didn't know about [2] before reading his entry.

dalf 7y ago

There is the Feature-Policy header too : allow and deny the use of browser features in its own frame. I've seen this header on a bank website. Example : Feature-Policy: accelerometer 'none'; autoplay 'none'; camera 'none'; fullscreen 'none' Documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Po...

wheresvic1 7y ago

For Node.js servers running on express, check out helmet[1] which adds a lot of these headers for you :) [1] https://www.npmjs.com/package/helmet https://www.npmjs.com/package/helmet

hcheung 7y ago

The nginx header directives are all not in correct syntax with the extra ":", and for those directives with multiple values, it should be wrapped within a "" (such as "1; mode=block"), here is the correct settings: ## General Security Headers add_header X-XSS-Protection "1; mode=block"; add_header X-Frame-Options deny; add_header X-Content-Type-Options nosniff; add_header Strict-Transport-Security "max-age=3600; includeSubDomains";