
HTTP security headers - mgdo
https://blog.appcanary.com/2017/http-security-headers.html
======
ivanr
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
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
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.

------
brianjking
Great writeup! Another resource that scans your site for various security
headers is [https://securityheaders.io/](https://securityheaders.io/).

~~~
simplehuman
This site does not seem to inspect http meta equiv headers.

~~~
zlynx
Meta headers are unreliable and mostly useless.

------
est
I feel HTTP access control (CORS) is missing

[https://developer.mozilla.org/en-
US/docs/Web/HTTP/Access_con...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Access_control_CORS)

~~~
kijin
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
> _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_con...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Access_control_CORS#Simple_requests)

~~~
kijin
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!

------
jwilk
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
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#Co...](https://wiki.mozilla.org/Security/Guidelines/Web_Security#Content_Security_Policy)

[1]: [https://csp-evaluator.withgoogle.com/](https://csp-
evaluator.withgoogle.com/)

[2]: [https://security.googleblog.com/2016/09/reshaping-web-
defens...](https://security.googleblog.com/2016/09/reshaping-web-defenses-
with-strict.html?m=1)

------
systematical
[http://securityheaders.io](http://securityheaders.io)

------
nemothekid
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
Firefox has never supported the X-XSS-Protection header.

------
Aaron1011
> 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
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.

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

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

