Now you can easily see if a site's HTTP headers are insecure, beams dev

Re: Hall of Shame

It's a tie between Sainsbury's Bank and The Register...

Re: Oh heck

Can you do mine while you're at it....

Re: Oh heck

I'll do the work for you! Just let me know which site you maintain and where the dangerous bits are. It's no trouble.

Re: Very arbitrary definition of "secure" headers

Not really, AC. Strict-Transport-Security doesn't rely on browser support to be useful. Every website should be served up over HTTPS, and every website should also implement the HSTS header, because for those browsers that support it - and bear in mind MS are working very hard to kill off IE <11 - it means there's never an HTTP request that needs redirecting after the first ever request to the site. There are also preload lists implemented by browsers.

Content-Security-Policy has one very simple setting - upgrade-insecure-requests - which you can set to ensure that none of the resources linked from within your page are ever served over HTTP. I don't understand how anyone could argue against that being a good idea. You can also set all sorts of other restrictions, which are great if implemented properly. At least having the header served up shows that a non-zero amount of thought has gone into external resources.

Public-Key-Pins is something everyone should just do. Serve up two pins - one relates to your private key, and the other relates to a backup private key. If you change your certificate, so what? It's the same private key, and hence the same public key. You serve up the backup pin in case your private key is compromised. It's a commonly held myth that the pin is for the certificate. It isn't. It's a hash on the public key. Not the same thing as a certificate.

Why wouldn't you set X-Frame-Options? What more efficient options are there for stopping your site being framed as phish bait?

Why wouldn't you set X-XSS-Protection? Leaving it unset allows IE to bypass its own filters for backward compatibility purposes. It's madness to suggest this means nothing. For IE, it means everything, and IE remains the number one target, even if it's no longer the most popular browser.

Why wouldn't you set X-Content-Type-Options? Are you suggesting it's OK not to set it if you couldn't be bothered declaring content types correctly? Or if you have someone who might use your site with an older browser? Screw those guys using newer browsers, because there's someone using an older browser which will ignore this header, I'm going to leave an XSS hole open for them.

Your caching safety headers will leak information to disk. They don't cut it. You should have said:

For HTTP 1.1:

Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0

For HTTP 1.0:

Pragma: no-cache

Expires: 0

An interesting comment, but in no measure a demonstration of understanding of web application security...

Re: Very arbitrary definition of "secure" headers

Hey, thanks for the comment, I'd thought I'd cover a few points.

HSTS may have poorer support in older browser, yes, but vendors aren't going to roll support for new security features backwards through their older versions. If you want support for the latest security features, you need to keep your browser up to date! ( http://caniuse.com/#search=hsts )

CSP has many more uses than just mitigating XSS, I've covered a few on my blog if you want to have a look at some more. CSP doesn't ensure security, I don't think anything can, but it's a step in the right direction. ( https://scotthelme.co.uk/tag/csp/ )

PKP is very rare yes and this is largely due to it being the most recently standardised of the headers and its higher complexity to implement. I'm not sure how it factors in to mobile apps, which wouldn't look at HTTP response headers, they'd key pin via other means if they did. As for native browsers on mobile platforms, they either support it or not, but in time all of them will I'm sure. Lastly, certificate renewal has no impact on PKP, you're pinning the Public Key (PK-Pin) and not the certificate. I currently issue the PKP header on my own site and automatically renew my certificate with Let's Encrypt ( https://scotthel.me/le ).

XFO is incredibly simple to deploy and widely supported, why would you not if you wanted to prevent framing? (or allow it from specific origins)

XXSSP, so if the filter is bypassed once we should abandon using it. Or perhaps the filters could be improved and continue to offer more robust protection moving forwards? The fact is that it does offer some protection which is always better than no protection, all for the sake of issuing a simple HTTP response header!

XCTO also helps to mitigate drive-by downloads if that poses a risk to your site, but even if it did only offer a marginal improvement against XSS, it's a very easy way to get it.

As for the other headers, there's a lot more coming but I couldn't get everything in to v1. Alongside Pragma and Cache-Control I'm looking at the Cookie header (httpOnly, secure) and the Access-Control-Allow-Origin header too. Any other suggestions for improvement are welcomed, you can leave a comment on my blog or find my email address and get in touch directly if you wish.

Scott.

https://scotthelme.co.uk

Re: Interesting

You found a score for an "E"? Did it involve Ebeneezer Goode?

Re: My bank website sucks?

Ah! Nevermind. It means 'redirect' and you can use the redirect link to scan correctly. Santander scores and 'F'. :P