8 ms·

HTTP security headers

224 points by mgdo 9y ago

brianjking 9y ago
Great writeup! Another resource that scans your site for various security headers is https://securityheaders.io/ https://securityheaders.io/.
- dbg31415 9y ago
  Don't forget https://observatory.mozilla.org/ https://observatory.mozilla.org/ (=
- simplehuman 9y ago
  This site does not seem to inspect http meta equiv headers.
  - zlynx 9y ago
    Meta headers are unreliable and mostly useless.
est 9y ago
I feel HTTP access control (CORS) is missing https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...
- kijin 9y ago
  If you don't return any CORS headers, all cross-origin requests will be blocked by default. If that's the behavior you want, there is no need to return any CORS headers.
  - deathanatos 9y ago
    > all cross-origin requests will be blocked by default "all" is a strong word. In the general case, you can make cross origin requests by doing <img src="http://api.the-latest-unicorn.io/v2/produce/rainbows"> or even <script src="..."> It's cross-origin, and it's a request, cookies will be sent with it, and if your GET requests have side-effects, you're going to have a bad time. You can even do POST requests, by making a <form> and auto-submitting it to the API with JavaScript. Of course, you're limited to certain MIME types, and notably not JSON. (And thank God for that.) Even if we assume that you only meant requests made by JavaScript via XHR, you can still make cross-origin requests. If you make an XHR request that looks like any of the above (specifically, if it meets the criteria for a "Simple Request"[1]), the browser will send it. It might not allow the JS that sent the request to view the response (if the response doesn't have the appropriate CORS headers), but the request still gets sent (because the response has to get received), and any side-effects can still happen. Thankfully, if you're writing a bog-standard JSON API, these usually don't apply … as long as you check your Content-Type header prior to decoding as JSON. (You are completely right, I think, that not returning any CORS headers is the most restricted — as far as CORS is concerned. My point being that sometimes, it's the response that gets blocked, not so much the request.) [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...
    - kijin 9y ago
      You're right, it's the response not the request that gets blocked. What's even worse, modern browsers will make an OPTIONS "preflight request" if you try to make a non-simple cross-origin request with XHR, whether with or without CORS. The actual GET or POST request might be blocked, but OPTIONS always goes through. So if your webapp doesn't distinguish between GET and OPTIONS, and if your GET actions have side effects, you're in for a nasty surprise!
est 9y ago
I feel HTTP access control (CORS) is missing https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...
nemothekid 9y ago
I think `X-XSS-Protection: 1; mode=block` is enabled by default in Chrome for all sites. I remember sending a malicious payload to one of my own pages and having the entire page blocked by Chrome (but not by Firefox).
- cknight 9y ago
  Firefox has never supported the X-XSS-Protection header.
Aaron1011 9y ago
> Unfortunately, as of writing, SameSite cookies are available only in Chrome and Opera, so you may want to ignore them for now. IIRC, the SameSite attribute is simply ignored by unsupported browsers. Is there any downside to setting it?
- rossy 9y ago
  I thought the same and I don't think there's a downside. I've been setting SameSite=strict for the session cookie in a B2B app for about a year and no one has complained. It's silently ignored by IE10 and Firefox, at least.
ivanr 9y ago
For some time now I've been working on a new project with the idea that you want to use a single testing tool that can give you comprehensive, coherent, and deep advice. It's early days and there's a lot to add still, but even now it's pretty good: https://www.hardenize.com https://www.hardenize.com Hardenize starts with the domain name (WHOIS), then DNS/DNSSEC/CAA, then email configuration (SMTP/STARTTLS/DANE/SPF/DMARC), then your web application (TLS/COOKIES/HSTS/HPKP/CSP/various headers, etc). Before Hardenize, I built SSL Labs.
- SamUK96 9y ago
  This sounds very interesting for budding platform developers. One problem is testing the more bespoke vuln routes - that's to say, the buffer overflows, the old package exploits, the strange oddities. By the sounds of it, you are building an "obvious security pitfalls" testing bot, which is in itself very valuable don't get me wrong, but i'm pushed to say that it's an NP problem to test bespoke vuln routes, which means the kind of testing process you are developing (linear-time problem solver) will struggle with testing the non-linear-time problems of bespoke vulns. However, I wish you luck, hats off to this, it's a great idea!
  - ivanr 9y ago
    My goal is to promote good engineering and security practices, and to make it easy to adopt them and deploy them correctly. I feel that's one area that doesn't get enough attention. At the same time, it's the only direction that will actually improve things in the long run. Chasing vulnerabilities is a fact of life, but even if you could eradicate them from your software today, you're not going to be safer tomorrow. To that end, Hardenize doesn't check for vulnerabilities. There's plenty of existing tools that do; I don't want to reinvent that wheel.
- hdhzy 9y ago
  Ivanr this is an excellent resource (just like SSL Labs) but I'm missing the "gamification" element: percentage points that make one strive for 100% (whether it is a good idea is a separate matter). Regarding DANE is there a benefit in deploying it now that browser vendors are against it? Also worth noting is that Key Pinning may be a very sharp knife.
systematical 9y ago
http://securityheaders.io http://securityheaders.io
jwilk 9y ago
HSTS is great... until the site's certificates expires, and then you have no way to override the security warning. Or if you want to untrust a shady CA, but you can't, because one of the site you (rarely) visits uses this CA + HSTS.
hdhzy 9y ago
Mozilla had an excellent resource [0] for security headers, especially Content Security Policy with examples for different use cases (e.g. APIs). See also Google's CSP Evaluator [1] and a blog post outlining security best practices [2]. It's surprisingly easy to make insecure policy that on the surface looks good, usually due to JSON-P endpoints on foreign endpoints. [0]: https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy https://wiki.mozilla.org/Security/Guidelines/Web_Security#Co... [1]: https://csp-evaluator.withgoogle.com/ https://csp-evaluator.withgoogle.com/ [2]: https://security.googleblog.com/2016/09/reshaping-web-defenses-with-strict.html?m=1 https://security.googleblog.com/2016/09/reshaping-web-defens...
5706906c06c 9y ago
Isn't X-Frame-Options deprecated? Pretty sure we're supposed to use Content-Security-Policy instead?
- hdhzy 9y ago
  Yes but there are still browsers that support only XFO so it's mostly for them.

224 points by mgdo 9y ago

Great writeup! Another resource that scans your site for various security headers is https://securityheaders.io/ https://securityheaders.io/.

dbg31415 9y ago
Don't forget https://observatory.mozilla.org/ https://observatory.mozilla.org/ (=
simplehuman 9y ago
This site does not seem to inspect http meta equiv headers.
- zlynx 9y ago
  Meta headers are unreliable and mostly useless.

est 9y ago

I feel HTTP access control (CORS) is missing https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...

kijin 9y ago
If you don't return any CORS headers, all cross-origin requests will be blocked by default. If that's the behavior you want, there is no need to return any CORS headers.
- deathanatos 9y ago
  > all cross-origin requests will be blocked by default "all" is a strong word. In the general case, you can make cross origin requests by doing <img src="http://api.the-latest-unicorn.io/v2/produce/rainbows"> or even <script src="..."> It's cross-origin, and it's a request, cookies will be sent with it, and if your GET requests have side-effects, you're going to have a bad time. You can even do POST requests, by making a <form> and auto-submitting it to the API with JavaScript. Of course, you're limited to certain MIME types, and notably not JSON. (And thank God for that.) Even if we assume that you only meant requests made by JavaScript via XHR, you can still make cross-origin requests. If you make an XHR request that looks like any of the above (specifically, if it meets the criteria for a "Simple Request"[1]), the browser will send it. It might not allow the JS that sent the request to view the response (if the response doesn't have the appropriate CORS headers), but the request still gets sent (because the response has to get received), and any side-effects can still happen. Thankfully, if you're writing a bog-standard JSON API, these usually don't apply … as long as you check your Content-Type header prior to decoding as JSON. (You are completely right, I think, that not returning any CORS headers is the most restricted — as far as CORS is concerned. My point being that sometimes, it's the response that gets blocked, not so much the request.) [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...
  - kijin 9y ago
    You're right, it's the response not the request that gets blocked. What's even worse, modern browsers will make an OPTIONS "preflight request" if you try to make a non-simple cross-origin request with XHR, whether with or without CORS. The actual GET or POST request might be blocked, but OPTIONS always goes through. So if your webapp doesn't distinguish between GET and OPTIONS, and if your GET actions have side effects, you're in for a nasty surprise!

est 9y ago

I feel HTTP access control (CORS) is missing https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...

nemothekid 9y ago

I think `X-XSS-Protection: 1; mode=block` is enabled by default in Chrome for all sites. I remember sending a malicious payload to one of my own pages and having the entire page blocked by Chrome (but not by Firefox).

cknight 9y ago
Firefox has never supported the X-XSS-Protection header.

Aaron1011 9y ago

> Unfortunately, as of writing, SameSite cookies are available only in Chrome and Opera, so you may want to ignore them for now. IIRC, the SameSite attribute is simply ignored by unsupported browsers. Is there any downside to setting it?

rossy 9y ago
I thought the same and I don't think there's a downside. I've been setting SameSite=strict for the session cookie in a B2B app for about a year and no one has complained. It's silently ignored by IE10 and Firefox, at least.

ivanr 9y ago

For some time now I've been working on a new project with the idea that you want to use a single testing tool that can give you comprehensive, coherent, and deep advice. It's early days and there's a lot to add still, but even now it's pretty good: https://www.hardenize.com https://www.hardenize.com Hardenize starts with the domain name (WHOIS), then DNS/DNSSEC/CAA, then email configuration (SMTP/STARTTLS/DANE/SPF/DMARC), then your web application (TLS/COOKIES/HSTS/HPKP/CSP/various headers, etc). Before Hardenize, I built SSL Labs.

SamUK96 9y ago
This sounds very interesting for budding platform developers. One problem is testing the more bespoke vuln routes - that's to say, the buffer overflows, the old package exploits, the strange oddities. By the sounds of it, you are building an "obvious security pitfalls" testing bot, which is in itself very valuable don't get me wrong, but i'm pushed to say that it's an NP problem to test bespoke vuln routes, which means the kind of testing process you are developing (linear-time problem solver) will struggle with testing the non-linear-time problems of bespoke vulns. However, I wish you luck, hats off to this, it's a great idea!
- ivanr 9y ago
  My goal is to promote good engineering and security practices, and to make it easy to adopt them and deploy them correctly. I feel that's one area that doesn't get enough attention. At the same time, it's the only direction that will actually improve things in the long run. Chasing vulnerabilities is a fact of life, but even if you could eradicate them from your software today, you're not going to be safer tomorrow. To that end, Hardenize doesn't check for vulnerabilities. There's plenty of existing tools that do; I don't want to reinvent that wheel.
hdhzy 9y ago
Ivanr this is an excellent resource (just like SSL Labs) but I'm missing the "gamification" element: percentage points that make one strive for 100% (whether it is a good idea is a separate matter). Regarding DANE is there a benefit in deploying it now that browser vendors are against it? Also worth noting is that Key Pinning may be a very sharp knife.

systematical 9y ago

http://securityheaders.io http://securityheaders.io

jwilk 9y ago

HSTS is great... until the site's certificates expires, and then you have no way to override the security warning. Or if you want to untrust a shady CA, but you can't, because one of the site you (rarely) visits uses this CA + HSTS.

hdhzy 9y ago

Mozilla had an excellent resource [0] for security headers, especially Content Security Policy with examples for different use cases (e.g. APIs). See also Google's CSP Evaluator [1] and a blog post outlining security best practices [2]. It's surprisingly easy to make insecure policy that on the surface looks good, usually due to JSON-P endpoints on foreign endpoints. [0]: https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy https://wiki.mozilla.org/Security/Guidelines/Web_Security#Co... [1]: https://csp-evaluator.withgoogle.com/ https://csp-evaluator.withgoogle.com/ [2]: https://security.googleblog.com/2016/09/reshaping-web-defenses-with-strict.html?m=1 https://security.googleblog.com/2016/09/reshaping-web-defens...

5706906c06c 9y ago

Isn't X-Frame-Options deprecated? Pretty sure we're supposed to use Content-Security-Policy instead?

hdhzy 9y ago
Yes but there are still browsers that support only XFO so it's mostly for them.