I've just deployed a few changes to Security Headers to bring it up to date with recent changes in the industry. Here are the details and how they might affect you.


Security Headers Sponsor

I announced sponsorship of the Security Headers project back in December 2016 and that continues through to this day. We had a great run with Netsparker as a sponsor and now Report URI has stepped in ensure this project continues on!



If you or your organisation might be interested in sponsoring Security Headers then please do get in touch using the sponsor page on the site.


Removing the X-Xss-Protection header

As the most popular platform that still runs an XSS Auditor, Chrome announced plans to drop it in an Intent to Deprecate and Remove: XSS Auditor. There are further details available in this bug but the TLDR is that the XSS Auditor is going. Recent changes included taking it from block mode to filter mode by default and it seems that wasn't enough to save it from the false positives. Edge removed their XSS Filter last year so with the removal from Chrome there is now no browser that will have a native XSS protection. It's time for the header to go! With that said, and using my site as an example, you can see that the X-Xss-Protection header is no longer required for an A+ grade on Security Headers.



You can still set the header, and indeed should because legacy browsers may exist for a long time, and we will still syntax highlight and positively mark the header in the Raw Headers section and Additional Information section.




Of course with the death of the XSS Auditor comes an increased value for Content Security Policy, an effective protection against XSS when deployed right.


Feature Policy now required for an A+

With the removal of the X-Xss-Protection header, another header has stepped into its place for the A+ grade to be achieved, Feature Policy. In that blog post I introduced Feature Policy and what it does and I also introduced it to Security Headers but with no grade impact. Today, that grade impact is introduced and a site without a properly configured Feature Policy header can't achieve an A+ grade.



The X-Frame-Options header can be replaced with CSP frame-ancestors

The X-Frame-Options header allows you to control which sites can place your site in an iframe and I covered it in my blog post on Hardening your HTTP response headers. Taking control of who can frame you is a good idea and the XFO header is required for an A+ grade on Security Headers. That said, the header isn't very flexible and doesn't offer much more functionality than being able to turn framing on or off. With the introduction of frame-ancestors in CSP you can now take much more flexible control over which sites can place your site in an iframe. With this far better level of control in CSP, Security Headers will now allow you to achieve an A+ while the XFO header is missing, as long as you have good controls in place with CSP frame-ancestors. Here is the Raw Headers and Additional Information section for my site, which does not set the XFO header.




As you can see I do not set the XFO header but I have frame-ancestors 'none' set in my CSP which offers the same level of protection, so my grade is not affected. We will allow any reasonable level of control in frame-ancestors but things like *, http: and https: aren't going to cut it and let you get the A+ grade.


Better CSP processing

To bring our grading up to date with CSP 3, we will no longer cap your grade for the presence of 'unsafe-inline' or 'unsafe-eval' if those unsafe keywords are found alongside a hash or nonce in the policy. 


default-src 'none';
script-src 'sha256-lYub1X6y/Vx1atPnp+PN039CtqzkIAT4j/JgXaBSfa4=' 'unsafe-inline';
style-src 'self' 'sha256-atKgzLsHpMfV5qfKsK9L5fNtfcOndgBPih9f3W0ZFyY=' 'sha256-ERPndH5xUrcjZhkNII2aUCkaIx14Oi89jPe8IJN4TiY=' 'unsafe-inline';


Previously, the policy above would have been capped at a grade A for the unsafe keywords but now the presence of the hash sources will save you and keep your A+ grade. This was a lot of new processing for us to update CSP parsing to be CSP 3 compatible so please do let me know if you spot any problems!


We have improved the analysis of Set-Cookie headers to include Cookie Prefixes and SameSite Cookies, both of which you can read about in my blog Tough Cookies. Here are the results for scanning Report URI and the cookie analysis that's taking place.




We can now detect and syntax highlight the Secure and HttpOnly flags, whilst also looking for SameSite and Prefixes. A SameSite setting of None will not get you a green highlight but Lax and Strict are both considered OK. We do have some detection in place for things like session/auth/csrf cookies to apply the appropriate requirements to, but of course it's not 100% accurate, we just do our best.


Better Syntax Highlighting

We've added syntax highlighting to a lot more headers and improved the existing syntax highlighting that was already there. It should now be a lot easier to look at headers at a glance and see what's going on with the policy inside them.



Better header processing

I found it really, really odd, but there were sites out there setting invalid header values that would sometimes still pass our validation just to get an A+ grade. Of course we never want this to be the case but I'd also never anticipated people trying to find ways to trick our processing and achieve an A+ by cheating. In the end I guess they're only cheating themselves and their visitors. That said, I still want our processing and grading to be reliable so I've taken all examples of such things that have been provided to me and improved our processing to be able to cope with them. It should now be a lot harder to cheat the system and achieve an A+ grade when you don't deserve one. That's not to say it's impossible, I'm quite sure there are still ways it could be done if you care to look hard enough, but I think things are generally a lot more reliable now.