HTTP Security Headers play an important role in the website’s security. They provide another level of security that helps mitigate several attacks and vulnerabilities that include SQL injection, XSS, clickjacking e.t.c
When a website is visited, the page is requested by the browser from the webserver. This server responds by sending content with HTTP response headers. These headers contain several data such as Cache-Control, Content-Encoding, status codes e.t.c. The gathered information from the headers can help you outline the communication and therefore improve your website’s security.
Enabling HTTP Security Headers in Nginx / Apache
The HTTP security headers that will be covered in this guide are:
- HTTP Strict Transport Security (HSTS)
- Content Security Policy (CSP)
- X-Frame-Options
- X-XSS-Protection
- X-Content-Type-Options
- Feature-Policy
- Permissions-Policy
- Expect-CT
These headers can be applied globally or to a specific site in the Nginx/Apache virtual host file by adding the HTTP Security Headers to the server block.
Now let’s plunge in!
1. HTTP Strict Transport Security (HSTS)
This header is used to allow the user agent to use an HTTPS connection only. It is normally declared using the Strict-Transport-Security
variable. This enhances the site’s security by ensuring that the connection through susceptible and insecure HTTP cannot be established.
This header can be implemented by adding the following entry to your virtual host file.
For Apache:
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
For Nginx
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
Below is an example of the Nginx config file with the added HTTP Strict Transport Security (HSTS) header.
upstream portal {
server localhost:8080;
}
server {
listen 80;
server_name portal.test;
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
location / {
proxy_pass http://portal;
}
}
Once the file has been added, restart the webserver to apply the changes.
2. X-Frame-Options
This header defends the website against clickjacking attacks by incapacitating iframes on your site. It will tell the browser whether to embed your website in an iframe or not. It is currently supported on Chrome 4.1+, Firefox 3.6.9+, IE 8+, Safari 4+, and Opera 10.5+.
Normally, there are 3 ways in which this header can be configured. These are:
- DENY – This option disables the iframe features completely.
- SAMEORIGIN – allows iframe features to be used by anyone from the same origin.
- ALLOW-FROM – allows iframe feature from specific URLs
Below is an illustration of how the X-Frame-Options header can be configured.
For Apache:
Header always set X-Frame-Options "SAMEORIGIN"
For Nginx.
add_header X-Frame-Options "SAMEORIGIN";
Once the changes have been saved, restart the webserver.
3. Content Security Policy(CSP)
This provides security against XSS(Cross-Site Scripting) and other code injection attacks. This is done by defining the approved content sources that allow the browser to load them. There are many derivatives that can be used in the Content-Security-Policy
entry.
For example, the below scripts allow content from the current domain(self)
For Apache.
Header always set Content-Security-Policy "default-src 'self'; font-src *;img-src * data:; script-src *; style-src *;"
For Nginx.
add_header Content-Security-Policy "default-src 'self'; font-src *;img-src * data:; script-src *; style-src *";
Save the changes and reload the browser.
4. X-XSS-Protection
X-XSS-Protection/Cross-Site Scripting header is used to protect the website against attacks by enabling the cross-site scripting (XSS) filter. This feature is enabled by default in modern browsers such as Safari, Internet Explorer 8+, and Google Chrome. This header normally prevents the page from loading whenever cross-site scripting (XSS) attacks are detected.
The header can be implemented in the following ways:
- X-XSS-Protection: 0 – disables the filter completely.
- X-XSS-Protection: 1 – enforces the header but only sanitizes potential malicious scripts.
- X-XSS-Protection: 1; mode=block – enforces the feature and completely blocks the page.
This feature can be enabled on your Web server by adding the desired implementation in your server block. For example:
For Apache
Header always set X-XSS-Protection "1; mode=block"
For Nginx.
add_header X-XSS-Protection "1; mode=block" always;
Apply the changes by restarting your web server.
5. Feature-Policy
This allows or denies the browser features whether in its frame or iframe. The header can be configured to look like this:
For Apache:
add_header Feature-Policy "autoplay 'none'; camera 'none'" always;
For Nginx
header always set Feature-Policy "autoplay 'none'; camera 'none'"
6. X-Content-Type-Options
This header is also known as the Browser Sniffing Protection. It is used to instruct the browser to follow the MIME types indicated in the header. It helps mitigate the danger of drive-by downloads. The header could look as below:
For Apache
header always set X-Content-Type-Options "nosniff"
For Nginx
X-Content-Type-Options: nosniff
7. Expect-CT
This header prevents any suspected certificates from being used. It allows the site to report and enable the certificate transparency requirements. When this header is enforced, the browser is requested to verify if the certificate appears in the public CT logs.
This header can be configured as below:
For Apache
header always set Expect-CT "max-age=604800, enforce, report-uri="https://www.example.com/report"
For Nginx.
add_header Expect-CT "max-age=604800, enforce, report-uri='https://www.example.com/report' always;
8. Permissions-Policy
This is a new header, it is used to control the APIs and features that can be used in a browser. This header can be enabled on the webserver as below:
For Apache.
Header always set Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()"
For Nginx.
add_header Permissions-Policy "geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()";
Save the changes and restart the webserver.
How to check your HTTP security headers
There are many ways you can check HTTP security headers on a site. Some of the methods covered here are:
1. Chrome DevTools response headers
This is a quick way to access the HTTP security headers. Navigate to Settings>More Settings > Developer Tools. While here, view response headers in the Network panel. Press Ctrl + R (Cmd + R) to refresh the page. Now click on the desired URL and view headers.

2. KeyCDN’s HTTP Header Checker tool
KeyCDN provides an online tool that can be used to check HTTP security headers. To use the tool, click on the link HTTP Header Checker and provide the URL to check the headers.

Click check to provide an HTTP response as below.

3. Security Headers.io
This is also another tool one can use to check HTTP security headers. This tool developed by Scott Helme scans and gives the website a score based on the available HTTPS headers. The score ranges from A+ to grade F. To use the tool, click on the link Security Headers

Provide the URL of the site and scan it. Below is a summary report for a grade C site.

I can improve the site to grade A+ by setting the required headers. The grade A site results will be:

Closing Thoughts.
That marks the end of this amazing guide. At this point, you can harden the security of your website using the knowledge gathered from this site. I hope this was significant to you.
Related posts.
- Best CompTIA Security+ (SY0-601) Certification Books
- Configuring oVirt / RHEV Manager Certificate Security on browser
- Install and Use WPScan – WordPress security scanner