HTTP Header Series: Security Headers

HyperText Transfer Protocol (HTTP) was developed in 1989 by Tim Berners-Lee at CERN.  With its basic request/response format, HTTP is possibly the most used communication technology of all time. Like any highly used technology we have seen numerous exploits in the more than two decades since its incarnation.  Each of these exploits has been met with a new “patch,” version or add-on to remedy the void.  One such remedy is they way in which web servers respond to browsers with instructions on exactly how it should behave.  This includes things like cache rules, meta data, authentication tokens and the topic of this post…security rules.

Defined and maintained by Open Web Application Security Project (OWASP), HTTP Security Headers help to:

1. Define what security precautions should be taken and in what cases
2. Fend off attacks and mitigate vulnerabilities
3. Reduce browser attacks such as clickjacking, injections, MIME sniffing, Cross-Site Scripting (XSS), etc.

To do this, OWASP defines a list of ten headers that should be included in each of your web server’s responses.  They are:

• HTTP Strict Transport Security (HSTS)
• X-Frame-Options
• X-Content-Type-Options
• Content-Security-Policy
• X-Permitted-Cross-Domain-Policies
• Referrer-Policy
• Feature-Policy
• Public Key Pinning Extension for HTTP (HPKP)
• Expect-CT
• X-XSS-Protection

We will cover most of these in more detail in future posts.  The ones that we don’t cover are likely deprecated or of low value.