Securityheaders.io – Analyse your HTTP response headers | Hacker News Reader

Securityheaders.io – Analyse your HTTP response headers

securityheaders.io

147 pointsrobin_reala46 comments

Thanks. I didn't know about X-Content-Type-Options! It is getting harder and harder to know all these headers nowadays. I am big fan of these checking tools with scores, it makes web developing entertaining. (A+! https://securityheaders.io/?q=https%3A%2F%2Fsatoshicrypt.com... )

I agree, I love these sorts of things because they make it easy to learn what you don't know. On the other hand, assigning an order based on an analysis like this can be interpreted wrongly, which I find annoying.

I agree, hopefully the majority will see benefit in it. It's intended as more of a way to educate rather than a definitive security assessment.

Glad it could help!

What I fear about HPKP is how easy it is to kill domain. You have to lose your keys once and it's lost domain for your users, because it's really hard for users to circumvent that protection. It's better to have a really good understanding of what's going on and have good key backups before you configure it.

You can also pin the public keys of certificate authorities to limit which ones can issue for your domain and not have to worry about key backups. GitHub do this as you can see here: https://report-uri.io/home/pkp_analyse/https%3A%2F%2Fgithub....

I also have a blog on the various places you can pin like the leaf, intermediate and root: https://scotthel.me/k2h

I don't think `X-XSS-Protection` is a worthwhile header to have. Every browser with XSS protection has it on by default. OWASP says this only exists to turn it on when a user may have turned it off (I have no idea why they would).

`Content-Security-Policy` is an awesome header, but in truth, it's very easy to misconfigure and even when correctly configured is usually fairly easy to bypass on any non-trivially complex website (for example, JSONP is an effective bypass for CSP). It's still worth looking into.

None of these things are a silver bullet for security but they're an improvement on the default settings.

JSONP only allows CSP bypass if you return anything other than JSON objects from an API. As long as you don't do that, CSP is fine.

Since JSONP allows you to have a callback, you can load this in script tags on the same domain and make calls to that / those functions.

First of all, thanks for sharing, I didn't know about many of these headers!

From recent scans I see that www.google.com got an E with missing headers:

    Strict-Transport-Security
    Content-Security-Policy
    Public-Key-Pins
    X-Content-Type-Options

Is this negligence on Google's part or ...?

https://securityheaders.io/?q=https%3A%2F%2Faccounts.google....

Looks like they just need a Content-Security-Policy and Public-Key-Pins.

Looking at Github's A+, can someone explain what's the point of pinning public keys for 300 seconds max?

https://securityheaders.io/?q=https%3A%2F%2Fgithub.com%2F

A lot of advice online, including my own, recommends that once you start enforcing a policy you keep the max-age quite short for a period of time. The report-only mode is helpful in identifying issues but given the nature of what HPKP is and does, jumping straight to a high max-age value when you start enforcing the policy isn't wise.

Yeah, we deployed this short max-age just to be safe on the initial deployment. I have a pull request open right now to switch our backup CA and add the intermediate certificate pins (to avoid possible future cross-signing issues) before we start bumping max-age. HPKP requires careful planning and a low max-age is definitely the way to go until you are 100% confident in your policy.

They don't use reporting.

When we first deployed our policy there was no support for reporting in browsers. I think that Firefox still lacks support and chrome only added support recently (I'd have to double check, or I'm sure Scott knows).

Exactly right. The only browser that will send HPKP reports right now is Chrome and that was very recent.

No, but that doesn't impact the operation of enforcing the use of their public keys which is the main purpose. It's definitely preferable to have reporting though.

Are there any good standalone, linux commandline tools of this kind (for ssl and mail config too)?

What other/similar analyzers are out there?

HTTPSecurityReport - https://httpsecurityreport.com - Disclaimer: I'm the creator.

Site Scan from MS - https://dev.windows.com/en-us/microsoft-edge/tools/staticsca...

Subresource Integrity scanner - https://sritest.io/

Maybe you can add HTTP2/SPDY detection too. BTW your HSTS test does not verify if the format/syntax is correct.

These are all good but I would include the following:

Qualys SSL Server Test - The first site I use.

testssl.sh - for behind the fireware testing

https://tls.imirhil.fr/ - this one is nice because it shows the ciphers used/avail broken down by TLS version. I have not seen any other site do this.

Thanks for these! I like that yours covered a lot more than the one OP posted.

Thanks, glad to hear it!

HTTPSecurityReport is great! Thank you!

For SSL from Qualys, Inc https://www.ssllabs.com/ssltest/

Last I checked, Qualys only scanned port 443. I like testssl.sh - you can point it at arbitrary ports:

https://testssl.sh/ https://github.com/drwetter/testssl.sh

testssl.sh is also great for testing internal servers which aren't internet accessible.

https://ssl-tools.net/ is nice because it will continously retest and email you if there's a problem. Also does mail servers

https://mxtoolbox.com/ can give some decent information when setting up a mail server.

There's also https://starttls.info/ which will check mail server configurations.

Huh, comes up with a cert warning. Looks like it's expired.

Kind of ironic (Firefox): http://i.imgur.com/p6RDBb4.png

This is also keeping the CSS from loading. (Chrome, however, displays beautifully.)

Strange, I get the same thing too despite the domain being among those whitelisted. I don't know how 'self' cannot equal securityheaders.io for a request to that domain.

I remember a while back when I was first using this I had a really difficult time getting it to work for a site I was doing. In the end, I had to remove all references to 'self' as a source and use the domain instead (even though these should be one and the same).

It's probably a Firefox bug.

Interesting, what version of Firefox is this? You can see in the CSP that 'self' is a defined keyword for both the script-src and style-src directives: https://report-uri.io/home/analyse/https%3A%2F%2Fsecurityhea...

44.0, but as it turns out, an update is available.

Did that fix it? Failing that, do you have any extensions or other things that might affect this?

Your latest change allowed me to whitelist azureedge.net in RequestPolicy. All of them say "A CSP report is being sent."

HPKP will accept if any of the fingerprints match -- I was wondering how I could transition certificates when using it, and hadn't noticed that fact. So to transition to a new certificate, specify the fingerprint of the old AND new certificates, for at least as long as the max-age. You can also specify the fingerprint of any certificate in the trust chain. I plan on pinning the let's encrypt certificate, instead of the specific certificates let's encrypt issues, and trusting let's encrypt to implement the domain validation correctly.

HPKP is HTTP Public Key Pinning, you aren't pinning certificates, you're pinning the public key. This means that you don't necessarily need to change any pins when you renew certificates as the certificate can use the same key pair. The only time you need to consume a backup pin when renewing the certificate is if you have a new public key signed. I think it's important to understand the difference before you try to deploy HPKP.

As for pinning the CA instead of your own public key, you can see my other comments in this thread with links about how GitHub pin their CA and a backup CA. I also have a link with information on the various levels in a chain you can pin at like the leaf, intermediate and root. Each has its own benefits and drawbacks.

I see, I hadn't made that obvious connection -- it's right in the name! (been awake for ~28 hours) That's much nicer. This is the first I've seen that header, it's good to know it exists -- I've implemented it in other ad-hoc protocols.

This site is awesome! That's why I've included on my OWASP Project. I'm just starting this project but it's going to have a lot information about security headers.