[Maarten Van Horenbeeck] [Information Security] [Resources]

HTTP Security Headers

Daemon.be sends a number of security headers. These headers were developed in various standards groups to help web sites specify to clients what behavior is expected and appropriate.

If you run Apache, you can set these same headers with the following configuration statements. Note that if you run a different HTTP and HTTPS virtualhost, you'll need to add them to both.

Header configuration


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

HTTP Strict-Transport-Security tells the client to always contact the site using HTTPS instead of HTTP, moving forward. Max-age should be long, as it tells the client how long to remember that the site should only be accessed over HTTPS. includeSubDomains notes that the rule applies to all sub-domains.

Header always set X-Frame-Options "SAMEORIGIN"

The X-Frame-Options header indicates where a browser is allowed to frame the content of your page from. In our case, we define it as such that any page served with the header can only be framed on the same origin as the page itself.

Header always set X-Content-Type-Options "nosniff"

X-Content-Type-Options tells the client that content-types are explicitly set by the server, and the client should not try to "guess" what content type is being delivered. This helps make sure that non-executable mime-types, uploaded by a less trusted user, are never parsed as executable mimetypes. Nosniff is the only valid option.

Header always set X-Xss-Protection "1; mode=block"

X-XSS-Protection enables XSS filtering in the browser. The mode=block statement tells the browser not simply to sanitize any attempt, but block rendering from the page altogether if XSS is detected.

Header always set Referrer-Policy: same-origin

Referrer-Policy offers meaningful privacy protection to users of your site. It tells the client whether Referrer information should be passed along when a client accesses a resource from the page being served. "Same-origin" specifies that referrer information should only be made available to requests going to the same origin, but not third party sites.

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

Content Security Policy is a complex protocol with many configurations and options. It helps mitigate specific categories attacks such as Cross Site Scripting. This specific statement tells the client that all content needs to come from our own origin, excluding subdomains. This is unlikely to work for complex sites, but serves a simple site like this one pretty well.

Full security header configuration block


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

Header always set X-Frame-Options "SAMEORIGIN"

Header always set X-Content-Type-Options "nosniff"

Header always set X-Xss-Protection "1; mode=block"

Header always set Referrer-Policy: same-origin

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

Subresource Integrity

In the case of the Daemon servers, all content is delivered directly from one machine under our control. For those who use a CDN, you can use Subresource Integrity, in combination with the Content Security Policy, to protect users from a compromise of that third party service. With subresource integrity, a webmaster can add a hash to any script or link element, using an integirty attribute. The browser will, upon downloading the script or stylesheet, validate the content against the expected hash in the integrity value. An example is as follows:

<script src="https://cdn.daemon.be/script.js"
        integrity="sha384-Px0j6MNGtBzeQjYcDPjWGyEzJGeeiMi0tHDMmlAyS8yo4fyWkRsy8iWAq0NUQKVl"
        crossorigin="anonymous"></script>

The "crossorigin" statement in this request tells the browser not to send any user credentials to cdn.daemon.be. SRI can be further strengthened by updating the Content-Security-Policy to require SRI for scripts, or style sheets. You do thiss by adding a simple header Content-Security-Policy: require-sri-for script; or Content-Security-Policy: require-sri-for style;.

More information

More information on security headers, as well as a nice testing tool, can be found at Scott Helme's Securityheaders.io site.