Every month I'm really happy to see securityheaders.io continuing to attract new users, get great feedback and be used and talked about more and more widely. With this increase in popularity comes the requirements to continually improve the service to keep everyone happy. Here is the latest round of updates!
securityheaders.io
If you haven't seen it, securityheaders.io is my free service that analyses the security of your HTTP response headers, go and check it out and scan your site for free! It's quick and easy to use, taking only seconds to complete and requires only the domain of the site you wish to scan. It does an assessment and provides you feedback on what was found.
If you want to see the detailed report for the results of scanning my site, you can see them here https://schd.io/1
Sponsorship
Probably the biggest change that anyone will notice is the addition of the new 'Sponsored by' message at the top of the site. The site has always been free, and always will be, but running it sadly isn't. After 18 months of running the service out of my own pocket, usage has now reached levels where a little financial support was required.
There are a few things I'd like to get clear first though. I didn't want to go down the advert route because frankly there were too many things I didn't like about it. They add a lot of bloat to the page, there are concerns over the security of the content, things like 3rd party tracking and most people would probably block them with ad blockers anyway! I opted for a sponsorship approach because I felt it was the best fit in many respects. First of all, there are no distracting, flashy banner ads that are going to annoy people and take away from the experience. The 'Sponsored by' message is self hosted and has no 3rd party dependencies or source. This means that no one can use it as a vector to do anything nasty, no one can track my visitors and there is basically no performance impact to speak of. Sponsors don't get access to any data or information from the site nor do they receive any preferential treatment. I've keep the best interests of my visitors and users in mind from the beginning and I'm happy with the outcome. If you'd like to sponsor the site that'd be awesome, please get in touch with me via email.
Grade caps
One of the things that has come up with the continued growth of the service is the need to introduce some kind of mechanism to cap grades in certain circumstances. Early on there were a few sites found 'cheating' their score and that was addressed some time ago, but there are now other scenarios creeping up where grades should perhaps be lower than they currently are. A good example of this is my site. The screenshot above shows my site getting an A+ grade but now it looks like this.
I no longer get an A+ grade and instead receive an A grade. Further down the page the reasons why are detailed.
Because my Content Security Policy header contains 'unsafe-inline' in the script-src directive the grade for my results is now capped at A. Allowing 'unsafe-inline' in the script-src directive is dangerous and removes a lot of the protection that CSP offers as we lose a strong defence against XSS attacks. You will also get a similar warning for the use of 'unsafe-eval' and I will be adding further restrictions over the coming weeks to CSP and other headers too.
Set-Cookie
The set-cookie header often comes up and I've taken an approach that I hope will strike a balance between valuable feedback and avoiding false positives. The problem with the set-cookie header is that I don't know whether the cookie is sensitive or not, like an auth cookie. To try and address this I'm looking for 3 sub-strings in the name that might indicate a sensitive cookie, sess, auth and login. Here is a section from the results for Twitter.
Only one of the set-cookie headers is being picked up here and it's because of the match on sess. Twitter uses HTTPS so the scan will check for the secure flag and it also expects httpOnly on any cookie that matches the sub-strings. If these criteria aren't met then the header will be marked yellow and a warning provided. Right now these don't count towards your grade, it's just feedback in the report. I want to introduce these measures and get some wider feedback on them before I add a weight for the scoring system.
CORS
The next header I've added support for the is the Access-Control-Allow-Origin header. Again, the checks here don't count towards your score yet but you will get feedback based on the settings of the header and eventually it will be something that grading is applied to. I have a whitelist setup for known CDNs so I can avoid throwing a warning when they are intended to have open CORS policies but if you see something that needs adding then please raise a bug.
Various other tweaks
I've also tidied up a few other items in this update and fixed a couple of minor bugs too. I've updated the UA string that the scanner uses and also set a more appropriate referer header so sites can understand what the traffic is if they get scanned. The report now handles duplicate headers properly, I've added all of the CSP 3 directives and made the input field more friendly for mobile devices. Nothing major, just a few bits to make using the site more pleasant.
If you have any feedback, comments or suggestions then please leave them below!