Homebrew header hardening
I’m at Homebrew Website Club. I figured I’d use this time to document some tweaking I’ve been doing to the back end of my website.
securityheaders.io is a handy site for testing whether your website’s server is sending sensible headers. Think of it like SSL Test for a few nitty-gritty details.
adactio.com was initially scoring very low, but the accompanying guide to hardening your HTTP headers meant I was able to increase my ranking to acceptable level.
My site is running on an Apache server on an Ubuntu virtual machine on Digital Ocean. If you’ve got a similar set-up, this might be useful…
I ssh’d into my server and went to this folder in the Apache directory
There’s a file called default-ssl.conf that I need to edit (my site is being served up over HTTPS; if your site isn’t, you should edit 000-default.conf instead). I type:
Depending on your permissions, you might need to type:
sudo nano default-ssl.conf
Now I’m inside nano. It’s like any other text editor you might be used to using, if you imagined what it would be like to remove all the useful features from it.
Within the <Directory /var/www/> block, I add a few new lines:
Header always set X-Xss-Protection "1; mode=block"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Those are all no-brainers:
- Enable protection against cross-site-scripting.
- Don’t allow your site to be put inside a frame.
- Don’t allow anyone to change the content-type headers of your files after they’ve been sent from the server.
If you’re serving your site over HTTPS, and you’re confident that you don’t have any mixed content (a mixture of HTTPS and HTTP), you can add this line as well:
Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"
To really up your paranoia (and let’s face it, that’s what security is all about; justified paranoia), you can throw this in too:
Header unset Server
Header unset X-Powered-By
That means that your server will no longer broadcast its intimate details. Of course, I’ve completely reversed that benefit by revealing to you in this blog post that my site is running on Apache on Ubuntu.
I’ll tell you something else too: it’s powered by PHP. There’s some editing I did there too. But before I get to that, let’s just finish up that .conf file…
Hit ctrl and o, then press enter. That writes out the file you’ve edited. Now you can leave nano: press ctrl and x.
You’ll need to restart Apache for those changes to take effect. Type:
service apache2 restart
Or, if permission is denied:
sudo service apache2 restart
Now, about that PHP thing. Head over to a different directory:
Time to edit the php.ini file. Type:
Or, if you need more permissions:
sudo nano php.ini
It’s a long file, but you’re really only interested in one line. A shortcut to finding that line is to hit ctrl and w (for “where is?”), type expose, and hit enter. That will take you to the right paragraph. If you see a line that says:
expose_php = On
Change it to:
expose_php = Off
Save the file (ctrl and o, enter) then exit nano (ctrl and x).
service apache2 restart
Again, you might need to preface that with sudo.
Alright, head on back to securityheaders.io and see how your site is doing now. You should be seeing a much better score.
There’s one more thing I should be doing that’s preventing me from getting a perfect score. That’s Public Key Pinning. It sounds a bit too scary for a mere mortal like me to attempt. Or rather, the consequences of getting it wrong (which I probably would), sound too scary.
This was originally posted on my own site.