How to add Security Headers to Your Site

This article will explain how you can add Security Headers in Apache. Security headers can be added directly to the .htaccess file of your site. The .htaccess file is typically located in the webroot of your site. A common location in Servebolt would be in the /public/ directory. You can access the .htaccess file by logging into your site using either SFTP or SSH. Editing the .htaccess file should be done by a more technical person, adding a rule wrongly may result in a 500 Internal Server Error. Adding the wrong Security Header to your site may also lead to some functionality not working as expected.

Adding Security Headers:

Security Headers can be added to your .htaccess file. The .htaccess file is parsed from top to bottom, so it is important that you keep that in mind when adding Security Headers.

Example:

The Security Headers added below are only an example of how it can look it on your .htaccess file. Use wisely and only add Security Headers to your site if you know what they do.

# Security Headers
<IfModule mod_headers.c>
Header set Content-Security-Policy "upgrade-insecure-requests"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header set X-Xss-Protection "1; mode=block"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=self"
</IfModule>


Why should I add Security Headers to my site?

Adding Security Headers to your site may be beneficial for various purposes. Some Security Headers add layers of security to your site, other headers tell modern browsers which browser features are allowed (Permissions-Policy).

What Security Headers should I add?

There are a lot of options available, and some of the options come with options of their own. HTTP security headers are a lot of fun, but in most cases also very site-specific. That is also why we don’t mention each and every option there is below since chances are that you won’t be needing all of them.

Different Security Headers and what they do:

In this section, we will explain what some of the Security Headers do. For more information on the various Security Headers.


Content-Security-Policy

The Content-Security-Policy header allows you to define approved sources for content on your site that the browser is permitted to load. By specifying only sources that you wish the browser to load content from, you can protect your visitors from a whole range of issues. It is an effective way of blocking Cross-Site Scripting (XSS) attempts. When setting up these headers it’s important that they are tested properly, since they allow what content will be loaded and what will be blocked. Blocking the wrong content might cause strange behavior on your site.

Example below, see documentation for use.

<IfModule mod_headers.c>
Header set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>

Strict-Transport-Security

The Strict-Transport-Security response header (also known as HSTS) lets a website tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

Example below, see documentation for use.

<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>


X-Xss-Protection

The X-XSS-Protection response header is a feature that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.

Example below, see documentation for use.

<IfModule mod_headers.c>
Header set X-Xss-Protection "1; mode=block"
</IfModule>


X-Frame-Options

The X-Frame-Options header is used to protect your visitors from possible clickjacking attacks. It instructs the browser on what sites are allowed to use a frame to embed your site. Because of this simplicity, it is an easy header to implement and it usually won’t cause issues.

Example below, see documentation for use.

<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
</IfModule>


X-Content-Type-Options

Another easy one to use is the X-Content-Type-Options. It only has one valid value, and if it’s set it prevents browsers from trying to mime-sniff the content-type of a response away from the one being declared by the server. As an effect, this reduces exposure to drive-by downloads and the risks of user-uploaded content that could be treated as a different content-type, like an executable.

Example below, see documentation for use.

<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
</IfModule>


Referrer-Policy

The Referrer-Policy requires a bit more thought. This will instruct the browser on what referrer to use when clicking on links to other sites. This can be useful in situations where you want to limit the amount of information being sent along with every click.

Example below, see documentation for use.

<IfModule mod_headers.c>
Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>


Permissions-Policy

This header used to go by the name Feature Policy, but since its introduction that has changed. So if any sites refers to the Feature Policy HTTP header, this is what they mean. This header allows you to disable or enable certain web platform features, on your own site, and on pages that you embed.

Example below, see documentation for use.

<IfModule mod_headers.c>
Header set Permissions-Policy "geolocation=self"
</IfModule>


How can I check my Security Headers?

If you already have added Security Headers to your site and want to see if they are valid or not, you can use the external tool of securityheaders.com to check that. Or you can check the headers of your site.