Response headers - an update

I previously wrote about what response headers I was sending back from my website - now I have an update.

Part of the problem was that extra headers were being sent, which I didn't particularly want to be sent.  So I've been working on getting rid of them.

X-Hostname

I believe this is added by my web host, but I managed to remove it by modifying my .htaccess file with the following...

  Header unset X-Hostname

X-Powered-By

This is added by PHP, but it was easily removed by modifying my php.ini file with the following...

  expose_php = Off

Server

I could not change this, unfortunately, due to the fact that I'm currently using shared hosting, and therefore don't have access.  But for others, whilst it can't be removed, it can be changed to minimise it's output, by adding the apache directives...

  ServerTokens ProductOnly
  ServerSignature Off

So now I've tidied that up a bit, I wanted to look at what else I should be adding.  I found an excellent site for this by Scott Helme called securityheaders.io.  You simply scan your site, and follow the advice it gives you.  

It warned me about the "Server" header, but I've already worked out I'm going to have to live with that.  Other headers it suggested that I add included...

Referrer-Policy

This is used to define what referrer information gets sent when someone clicks on a link on your site that goes to another site, or even a page within your own site.  Scott Helme has written a great blog post on this, in which he recommends going with "no-referrer-when-downgrade", which sounds good enough for me.  My site is currently shipped over HTTP, but when I move it to HTTPS (yes, this is the plan!) then it will ensure referrer information isn't passed on to HTTP sites.

Content-Security-Policy

This is used to control what access different content on your site has.  For example, you can control what javascript and stylesheets can be included, inline or from different domains, etc.  Again, Scott Helme has written another great blog post on this.  He has also created an excellent site called report-uri.io which has a number of tools, including one to help you build your CSP.  This is a bit more involved though, so I think I'll cover this in a separate post.

Response headers

One thing that you need to decide when creating a site is what response headers to send when someone requests your page.  There are also a couple of different ways of sending them.  

Using .htaccess

  <IfModule mod_headers.c>
    Header set Connection keep-alive
  </IfModule>

Using PHP code

  header("Connection: keep-alive");

So what headers am I setting on my website and why?

1) X-Frame-Options: deny

This is the best way to guard against Clickjacking attacks, but telling the browser that it should never allow the site to be run within an iframe or frameset, and therefore cannot be embedding within another site.

2) X-Content-Type-Options: nosniff

This tells the browser not to try and guess the content type of a response and to always use the one being declared by the server. It reduces exposure to drive-by downloads and the risks of user uploaded content that, with clever naming, could be treated as a different content-type, like an executable.

3) X-Permitted-Cross-Domain-Policies: none

When clients request content hosted on a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain in order to allow the client to continue the transaction.  I don't have any content like this, so I've set it to "none".

4) X-XSS-Protection: 1; mode=block

This tells the browser to protect against Cross-Site Scripting (XSS) attacks, and to block any attempts instead of trying to sanitise them.  This won't stop all XSS attacks, but it's a good baseline.

Now, if you check out the headers in the Network tab of your browser's Developer Tools, you'll see there are also some extras...

There are two types of extras...

Automatically created by the server - these are useful!

• Cache-control
• Content-Encoding
• Content-Length
• Content-Type
• Date
• Expires
• Vary

Automatically added by my web host - these are not useful!

• Server
• X-Hostname
• X-Powered-By

These reveal information to an attacker which they may be able to use to assist them, which is not good.  If I figure out how to remove them, I'll let you know in a future post.