Security Headers

This article will explain how you can add security headers to Apache. You can add security headers directly to your site’s .htaccess file. 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 SFTP or SSH. A more technical person should edit the .htaccess file. Adding a rule wrongly may result in a 500 Internal Server Error. Moreover, adding the wrong Security Header to your site may also lead to some functionality not working as expected. Therefore, it’s crucial to verify your settings carefully.

Adding Security Headers:

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

Example:

The Security Headers added below are only an example of how it can look 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. However, some security headers add layers of security to your site, while 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:

This section 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 can load. By specifying only sources you wish the browser to load content from, you can protect your visitors from a 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 because they determine what content will be loaded and what will be blocked. Blocking the wrong content might cause strange behaviour on your site.

For the example below, see the 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 (HSTS) lets a website tell browsers that it should only be accessed using HTTPS instead of HTTP.

For the example below, see the 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.

For the example below, see the documentation for use.

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


X-Frame-Options

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

For the example below, see the 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. 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.

For the example below, see the 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 policy instructs the browser 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 sent with every click.

For the example below, see the documentation for use.

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


Permissions-Policy

This header used to be called Feature Policy, but that has changed since its introduction. So, if any sites refer 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.

For the example below, see the documentation for use.

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


How can I check my Security Headers?

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