HTTP Security Response Headers Recipe
Give your web server a security headers tuneup, one step at a time
While working with a few people recently to help them learn how to configure the HTTP Security Response Headers (aka Security Headers) for their websites, I was reminded of my own struggle to wrap my head around the concepts involved.
The subject has a certain depth of complexity — you could spend some days going down the rabbit hole of all the CSP (Content Security Policy) options for example — and there’s an enormous amount of documentation on the web about this.
Some of that documentation is truly excellent like that from Mozilla Foundation or the many fine articles on Scott Helme’s blog.
Other efforts may be a bit less excellent, but still quite useful.
As with any other subject though, there’s also an alarming amount of utterly silly SEO spam and low-effort noise pollution, cluttering the search results.
It can be daunting. Where does one start? Which header to set first?
The vast majority, as counted by the number of different web pages, is quick-and-dirty advice for setting a single security header, maybe on a particular web server.
What’s missing, at least I haven’t found it, is guidance for the learning path.
So here it is. This is how I teach people how to learn about security headers and protect their websites from cross-site scripting attacks.
As it turns out, if you approach learning about security headers and dive into the CSP first, because that seems most important, the experience can be quite frustrating.
However, if you follow this recipe, you’ll be able to walk the path without falling into subterranean cavernous rabbit hole.
This recipe takes the frustration out of learning about security headers and securing yoru website.
I hope you’ll find this useful. Please feel free to provide feedback or any additional tips you may have.
The Quickest Way to Secure Your Website against Cross-Site Scripting (XSS) Attacks with HTTP Security Response Headers
If you do these steps in this order, you, too, can configure your security headers and very quickly get an A or A+ rating on your website!
1️⃣ Set the "Strict-Transport-Security" header and then resolve any TLS issues that might be revealed.
2️⃣ Scan the site with a security headers scanner (there are several free ones online, I'll link to one in the comments below).
3️⃣ Set each of the security response headers that are recommended by the scanning tool, *except* for the Report-URI and the CSP (Content Security Policy). Save CSP and Report URI for the next phase. This should get your website score up to a "B" or maybe an "A".
4️⃣ Configure the reporting and set the Report-URI security response header. You want this working before you tackle the final step. DO NOT SKIP THIS STEP. It’s extremely useful to have the reporting set up, before you work on configuration the CSP.
5️⃣ Finally, use the "CSP Wizard" (link in comment below) to generate your CSP (Content Security Policy) and set the Content-Security-Policy
Following this recipe for configuration of HTTP Security Response Headers, you can quickly improve the security of your websites and protect your organization, your customers, and your data from cross-site scripting (XSS) attacks.
An Important Note About Deployment of CSP (Content Security Policy
Configuring most of the Security Response Headers even on high traffic, highly complex websites is fairly straightforward and relatively low risk, especially if the organization is using contemporary best practices for DevOps and DevSecOps.
The Content-Security-Policy (CSP) header is quite a bit more complex, however. This security header is extremely important, and arguably provides the best protection from the widest variety of possible cross-site-scripting attacks (of which there are, literally, tens of thousands!) but you’ll want to take a little extra care while deploying this configuration change.
If the CSP for a site is defined incompletely, it might disallow important resources from being loaded, resulting in a poor user experience. This problem is pretty easy to avoid, however.
If your website is complex, or if you need to test your newly minted CSP (Content Security Policy) on a production (live) website without enforcing the policy, there’s a handy mode set by the “Content-Security-Policy-Report-Only” which, when set instead of “Content-Security-Policy” will tell you (via the Report-URI logging mechanism) what resources would be blocked as traffic flows into your site, without actually blocking any of those resources.
This is an elegant testing mechanism which allows you to test your CSP with no risk, adjust it as needed, and then deploy it merely by changing the header name from “Content-Security-Policy-Report-Only” to “Content-Security-Policy” in your configuration file.
For details see the excellent Mozilla developer documentation:
Content-Security-Policy-Report-Only
Resources for Securing Your Website
Learning About HTTP Security Response Headers
OWASP — HTTP Security Response Headers Cheat Sheet
Scott Helme — his website with tons of stuff about security headers
Understanding and Configuring Content Security Policy on Your Web Server
Content Security Policy — Report URI Documentation
Content-Securty-Policy Security Header Quick Reference
Mozilla Documentation for Content Security Policy (CSP)
Content-Security-Policy-Report-Only mode (Mozilla documentation)
Configuring Security Headers on Nginx
Nginx quick start guide (starting, stoping, configuring)
OWASP — Nginx example configuration for HTTP Security Response Header
Scott Helme — Nginx related blog posts
Configuring HTTP Security Response Headers on Microsoft IIS
Add a custom HTTP response header to a web site that is hosted by IIS
Free Online Scanners for HTTP Security Response Headers
There are dozens of free scanners for web server security headers available on the Internet. These are the two that I use most often.
Security Headers .com (Powered by Probely)
HTTP Security Response Headers Freescan (by Securily)