A commenter on my old post about configuring security headers on Nginx (and getting an A or A+ rating on securityheaders.io, now moved to securityheaders.com) asked for a version for Apache, so… here it is. It’s basically the same, just with the appropriate syntax changes:
| Nginx setting | Explanation |
| header always set Strict-Transport-Security “max-age=31536000; includeSubdomains; preload” | Enforces HTTPS on the entire site. Don’t use if you still need to provide HTTP, of course. |
| header always set X-Content-Type-Options nosniff | Prevents browsers from trying to “guess” MIME types and such, forcing them to use what the server tells them. |
| header always set X-Frame-Options SAMEORIGIN | Stops your site from being included in iframes on other sites. |
| header always set X-Xss-Protection “1; mode=block” | Activates cross-scripting (XSS) protection in browsers. |
| header always set Referrer-Policy “unsafe-url” | Makes the site always send referrer information to other sites. NOTE: this is not the most secure setting, but it’s the one I prefer; see below. |
| header always set Content-Security-Policy “default-src https: data: ‘unsafe-inline’ ‘unsafe-eval'” | Forces TLS (don’t use if you still need to provide HTTP); prevents mixed content warnings. NOTE: again, this is not the most secure setting; see below. |
About the last two settings, I’ll copy from my old post:
I choose to send referring information to other sites for a simple reason: I like to see where my own visitors come from (I don’t sell, share or monetize that in any way, it’s just for curiosity’s sake), and I’m a firm believer in treating others as I want to be treated. If you don’t care about that, you may want to change this to “no-referrer-when-downgrade“, or “strict-origin“.
As for the Content Security Policy, anything more “secure” than the above prevents (or at least makes it a lot more headache-inducing) the use of inline scripts and/or external scripts, which would mean no external tools/scripts/content (or at least a lot of work in adding every external domain to a list of exceptions), and a lot of hacking on software such as WordPress (seriously: add the setting, but then remove the “unsafe-*” options and see what stops working…). You might use the most paranoid settings for an internally developed, mostly static site, but I fail to see the point. So, this and the paragraph above are the reasons for an A rating, instead of an A+.
Hope this was useful. 🙂
There’s a new header called “Feature-Policy”, supposed to specify which features and APIs a site can use. Apparently, it still doesn’t have much browser support (Firefox doesn’t support it, for instance), but if you want, you can play with it. If you simply want to prevent securityheaders.com from complaining about it, you can add something harmless like:
header always set Feature-Policy “midi none”
unless, of course, you have a site that’s supposed to play MIDI music on visitors’ browsers. Unlikely in 2019, I’d guess. 🙂