Modern web browsers offer a lot of security features aimed at protecting your users from a wide variety of threats such as malware installed on their device, hackers listening to their network traffic and malicious phishing sites pretending to be something that they’re not. Unfortunately quite a few of these features are disabled by default in order to ensure backward compatibility with older websites that rely on insecure behavior to function properly. What a lot of developers don’t know is that many of these settings are actually incredibly simple to enable, and you can protect your app from a wide variety of attacks in less than an afternoon. Here is a list of the most important security HTTP headers and why you should care about them.
1. Frame Options
Setting an X-Frame-Options header on your website is a way to protect from someone creating a wrapper around your site doing whatever they want and displaying your page in an iframe. This allows attackers to force your users to click on some part of your website, while hidden in an iframe (these are known as clickjacking attacks). You can either choose to completely block rendering your site inside a frame by setting this header to DENY, allow it to be rendered by other pages on the same server with SAMEORIGIN or, you can specify a list of whitelisted domains with ALLOW-FROM.
2. XSS Auditor
Cross-site scripting (XSS) is one of the most common and dangerous type attacks on the web, as it is often used to inject malicious code into your app to extract data about a logged in user, or take advantage of their user privileges to perform actions not available by default. Setting the X-XSS-Protection header allows modern browsers to block attackers from Reflected XSS attacks.
3. Content Type Options
Some browsers try to be smart and guess the type of file being transferred by default. This allows the browser to render an HTML file if the content looks right even if the server says that the file is plaintext. This can be used as an attack vector for untrusted JavaScript code. Setting the X-Content-Type-Options header to nosniff force browsers to respect the server specified file type.
4. HTTP Strict Transport Security
Strict Transport Security tells browsers they should refuse to connect to this website as HTTP, which prevents connections from insecure locations to be downgraded from HTTPS to HTTP by an attacker. If the initial connection to a website is made over HTTP and redirected to HTTPS, the HSTS header will force further connections initiated by the user to only go through HTTPS.
5. Public Key Pinning Extension for HTTP
Public Key Pinning Extension for HTTP is another header that is only useful for sites running on HTTPS. While this header won’t do anything the first time, a user loads your site it will register the certificate your site is using, preventing your user’s browser from connecting to a malicious server with a different certificate that is pretending to be your website. This can be especially useful to protect your users against attackers who can create certificates for any domain (e.g. from abusing a trusted Certificate Authority or finding an HTTPS flaw).
6. Content Security Policy
Most of the other headers introduced here are quite simple, although I’ll have to admit that this one does take a little bit of effort to implement. A Content Security Policy (CSP) header lists all authorized domains and resources your app is allowed to use. Thus if a user loads a page where an attacker has injected a malicious resource, the browser will load your page, but prevent the attacker’s resource from loading. One side effect of using this header is that if you add new assets to your application, you will need to update your Content Security Policy accordingly. We recently released a new feature on Sqreen allowing you to enable easily and manage over time your CSP. You can read more about it in this article.
7. Cookie Protection
If you’re using cookies to store session or authentication information to keep users logged into your site, there are a couple of tricks to improve your security. There are two directives you should add which protect attackers from reading cookies in different places:
- HttpOnly will forbid JavaScript from accessing cookies which will prevent an XSS attack from being able to send your user’s cookies to the attacker.
- The Secure attribute will only allow the cookies to be transferred over an HTTPS connection and not over HTTP, so an attacker with access to your network won’t be able to read unencrypted cookies.
Summary
| HTTP Security Header | Browser Compatibility | Usefulness | Easiness |
|---|---|---|---|
| Frame Options | Link | ★★ | ★★★★★ |
| XSS Auditor | n/a | ★★ | ★★★★★ |
| Content Type Options | n/a | ★★ | ★★★★★ |
| HTTP Strict Transport Security | Link | ★★★ | ★★★★ |
| Public Key Pinning Extension for HTTP | Link | ★★★★ | ★★ |
| Content Security Policy | Link | ★★★★★ | ★ |
| Cookie Protection | n/a | ★★★★★ | ★★★ |
Myheaders.sqreen.com
We have built a simple tool to help you know if your website has all of these critical security headers enabled. Go to https://myheaders.sqreen.com to see if your website is protected.
About the author
Alexander Ottenhoff is an Australian Full Stack software engineer living in Paris. He is a strong believer that all software will eventually run in a web-browser and embraces the JavaScript future.
