Security headers

Adding security headers to your .htaccess file can help to secure your website and its data. This article explains how to add the following security headers.

• Content-Security-Policy
• Strict-Transport-Security (HSTS)
• X-Frame-Options
• Cross-site Scripting protection (XSS)
• X-Content-Type-Options
• Referrer Policy
• Feature-Policy
• CORS headers

The examples in this article assume your site is on an Apache server and you are adding headers to your site's .htaccess file. View the following article for an overview of what an .htaccess file is and how to add one to your site.

• .htaccess overview

The Content-Security-Policy header specifies approved sources of content that the browser may load from your website. When you whitelist approved content sources, you thereby help to prevent malicious code from loading on your site. This is a way to help reduce XSS risks. 

View the following page for further details:

• https://content-security-policy.com/

This example allows any asset to be loaded only from your website.

Header set Content-Security-Policy "default-src 'self'"

This example allows any asset to be loaded from your domain over HTTPS on port 443 only.

Header set Content-Security-Policy "default-src https://example.com:443"

You can then test if it's active by running the following curl command via SSH:

[server]$ curl -I https://example.com
HTTP/1.1 200 OK
Date: Fri, 29 Mar 2024 22:17:47 GMT
Server: Apache
Last-Modified: Fri, 29 Mar 2024 17:05:19 GMT
ETag: "2f5-56a72ed086011"
Accept-Ranges: bytes
Content-Length: 757
Content-Security-Policy: default-src https://example.com:443
Content-Type: text/html

Resolving insecure site and mixed-content warnings

If your website has any assets that load over http, your site will display an SSL warning in the URL bar of your browser to notify the visitor that the connection is not safe.

• Resolving insecure site and mixed-content warnings

The following code upgrades all requests to insecure resources automatically. This fixes the SSL warning in your browser.

Header always set Content-Security-Policy "upgrade-insecure-requests;"

Strict-Transport-Security headers tell the browser to ONLY interact with the site using HTTPS and never HTTP. View the following pages for further details.

• en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
• cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html

You can enable this in your .htaccess file with the following code:

Header set Strict-Transport-Security "max-age=31536000;includeSubDomains;"

You can then test if it's active by running the following curl command via SSH:

[server]$ curl -I https://example.com
HTTP/1.1 200 OK
Date: Fri, 29 Mar 2024 20:05:52 GMT
Server: Apache
Last-Modified: Fri, 29 Mar 2024 16:26:52 GMT
ETag: "2f9-56de78493cbc8"
Accept-Ranges: bytes
Content-Length: 761
Strict-Transport-Security: max-age=31536000;includeSubDomains;
Content-Type: text/html

hsts preload and the 'www' subdomain

Chrome offers you the option to add your domain to their HSTS preload list.

• https://hstspreload.org

This test will fail if your site is forcing the 'www' subdomain in the panel.

• Add or remove www from a domain

To past the test, this option must be set to 'Leave it alone'.

Adding the 'www' subdomain in the panel will cause the HSTS preload check to fail with the following message.

`http://example.com` (HTTP) should immediately redirect to `https://example.com`
(HTTPS) before adding the www subdomain. Right now, the first redirect is to 
`http://www.example.com/`. The extra redirect is required to ensure that any 
browser which supports HSTS will record the HSTS entry for the top level domain,
not just the subdomain.

Cloudflare

If you wish to use Cloudflare and add your domain to the HSTS preload list, you must purchase a Cloudflare account directly from Cloudflare.

This header helps to protect your visitors against clickjacking attacks. Add this header on pages that should not be allowed to render a page within a frame. View the following links for further information:

• keycdn.com/blog/x-frame-options
• developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

This example completely disables the ability to load any page in a frame.

Header always set X-Frame-Options DENY

This example only allows your website to embed an iframe on your pages.

Header always set X-Frame-Options SAMEORIGIN

You can then test if it's active by running the following curl command via SSH:

[server]$ curl -I https://example.com
HTTP/1.1 200 OK
Date: Fri, 29 Mar 2024 22:49:51 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Last-Modified: Fri, 29 Mar 2024 17:05:19 GMT
ETag: "2f5-56a72ed086011"
Accept-Ranges: bytes
Content-Length: 757
Content-Type: text/html

The X-XSS-Protection header helps to protect your visitors against Cross-site Scripting attacks. View the following article for further details:

• developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

In this example, the value 1 is used. This enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).

Header set X-XSS-Protection "1"

In this example, the value 1; mode=block is used. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.

Header set X-XSS-Protection "1; mode=block"

You can then test if it's active by running the following curl command via SSH:

[server]$ curl -I https://example.com
HTTP/1.1 200 OK
Date: Fri, 29 Mar 2024 22:55:52 GMT
Server: Apache
Last-Modified: Fri, 29 Mar 2024 17:05:19 GMT
ETag: "2f5-56a72ed086011"
Accept-Ranges: bytes
Content-Length: 757
X-XSS-Protection: 1; mode=block
Content-Type: text/html

This header blocks content sniffing that could transform non-executable MIME types into executable MIME types. View the following article for further details:

• developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Header set X-Content-Type-Options nosniff

You can then test if it's active by running the following curl command via SSH:

[server]$ curl -I https://example.com
HTTP/1.1 200 OK
Date: Fri, 29 Mar 2024 23:10:02 GMT
Server: Apache
Last-Modified: Fri, 29 Mar 2024 17:05:19 GMT
ETag: "2f5-56a72ed086011"
Accept-Ranges: bytes
Content-Length: 757
X-Content-Type-Options: nosniff
Content-Type: text/html

This header controls how much referrer information from your site is sent to another server. For example, if a link on your site opens a different website, that website's server records your domain name as the referrer of that link. With this policy, you can control what referrer information is sent to that external server. View the following link for further details.

• developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

This example does not send any referrer information.

Header set Referrer-Policy: no-referrer

You can then test if it's active by running the following curl command via SSH:

[server]$ curl -I https://example.com
HTTP/1.1 200 OK
Date: Fri, 29 Mar 2024 00:40:50 GMT
Server: Apache
Last-Modified: Fri, 29 Mar 2024 00:33:15 GMT
ETag: "391-5983506a2c574"
Accept-Ranges: bytes
Content-Length: 913
Referrer-Policy: no-referrer
Content-Type: text/html

The Feature-Policy header controls which browser features are allowed on your website. This policy allows the website owner/developer to restrict specific APIs the site can access in the browser. Here are a few examples:

• Change the default autoplay behavior on videos.
• Restrict the site from using a camera or microphone.
• Disable the Geolocation API.

This is important if the site allows third-party content as it helps to control what those third-party apps may attempt to do with the user's browser when someone visits your website. View the following links for further information.

• developers.google.com/web/updates/2018/06/feature-policy
• developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy

This example blocks the Geolocation API in the browser from functioning on your site.

Header set Feature-Policy: "geolocation none"

You can then test if it's active by running the following curl command via SSH:

[server]$ curl -I https://example.com
HTTP/1.1 200 OK
Date: Fri, 29 Mar 2024 01:00:49 GMT
Server: Apache
Last-Modified: Fri, 29 Mar 2024 00:33:15 GMT
ETag: "391-5983506a2c574"
Accept-Ranges: bytes
Content-Length: 913
Feature-Policy: geolocation none
Content-Type: text/html

View the following article for information on how to configure CORS headers.

• CORS headers