HTTP Security Headers Best Practices


There are a lot of things to consider to when securing your website or web application, but a good place to start is to explore your HTTP security headers and ensure you are keeping up with best practices. In many cases they are very easy to implement and only require a slight web server configuration change. HTTP security headers provide yet another layer of security by helping to mitigate attacks and security vulnerabilities. In this post we will explore some of them to help you better understand their purpose and how to implement them.

What Are HTTP Security Headers Exactly?

When a user tries to access a page, his browser requests it from a web server. The server then responds with the content along with appropriate HTTP Response Headers which contain meta data, status error codes, cache rules and so on. A big subset of those headers are security headers which instruct your browser exactly how to behave when it handles your website’s content and data.

There are different HTTP security headers that we will explore below (in no particular order) that you should be aware of and we recommend implementing if possible.


  1. Content Security Policy

The content-security-policy HTTP header provides an additional layer of security. This policy helps prevent attacks such as Cross Site Scripting (XSS) and other code injection attacks by defining content sources which are approved and thus allowing the browser to load them. All major browsers currently offer full or partial support for content security policy. And it won’t break delivery of the content if it does happen to be delivered to an older browser, it will simply not be executed. There are many directives which you can use with content security policy. This example below allows scripts from both the current domain (defined by ‘self’) as well as

content-security-policy: script-src ‘self’


  1. X-XSS-Protection

The x-xss-protection header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. This is usually enabled by default, but using it will enforce it. It is supported by Internet Explorer 8+, Chrome, and Safari. Here is an example of what the header looks like.

x-xss-protection: 1; mode=block

Enable in Nginx

add_header x-xss-protection “1; mode=block” always;

Enable in Apache

header always set x-xss-protection “1; mode=block”


  1. HTTP Strict Transport Security (HSTS)

The strict-transport-security header is a security enhancement that restricts web browsers to access web servers solely over HTTPS. This ensures the connection cannot be establish through an insecure HTTP connection which could be susceptible to attacks. All major modern browsers currently support HTTP strict transport security except for Opera Mini and versions previous of Internet Explorer. Here is an example of what the header looks like. You can include the max age, subdomains, and preload.

strict-transport-security: max-age=31536000; includeSubDomains; preload


  1. X-Frame-Options

The x-frame-options header provides clickjacking protection by not allowing iframes to load on your site.  It is supported by IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+. Here is an example of what the header looks like.

x-frame-options: SAMEORIGIN

Enable in Nginx

add_header x-frame-options “SAMEORIGIN” always;

Enable in Apache

header always set x-frame-options “SAMEORIGIN”


  1. Public-Key-Pins

The public-key-pins header tells the web browser to associate a public key with a certain web server to prevent MITM attacks using rogue and forged X.509 certificates. This protects users in case a certificate authority is compromised.


  1. X-Content-Type-Options

The x-content-type header prevents Internet Explorer and Google Chrome from sniffing a response away from the declared content-type. This helps reduce the danger of drive-by downloads and helps treat the content the right way. Here is an example of what the header looks like.

x-content-type: nosniff

Enable in Nginx

add_header X-Content-Type-Options “nosniff” always;

Enable in Apache

Header always set X-Content-Type-Options “nosniff”



HTTP security headers are a great way to tighten your website’s security. There is actually no logic scenario when you shouldn’t use them. By setting up your security headers correctly not only you help protect your site, but your users as well. This will also help you cut down on security flaws and working hours invested in tracking and fixing them. Setting security headers the right way and keeping them up to date will greatly reduce the amount of risk mitigation actions needed in the future. Hopefully, this best practices will help you with that.

Leave a Reply

Your email address will not be published. Required fields are marked *