Configuring Critical HTTP Security Headers For Your Web Applications & Web Services

In Hypertext Transfer Protocol, HTTP security headers comprise of components of the header section of the request and response messages that define the operating parameters of an HTTP transaction.

HTTP security headers allow clients and servers to pass additional information together with the requests or responses.

By implementing appropriate headers in the response, most security vulnerabilities such as clickjacking, code injection, MIME types, cross sites scripting (XSS) and other attacks can be mitigated.

These security headers further instructs clients’ browsers on how to respond when handling site’s content.

Besides the default headers, it was previously possible to create custom headers using a prefix ‘X-‘ but this was deprecated in June 2012 due to inconsistences in the required standard fields.

HTTP Security Header Types

HTTP security headers can basically be grouped into general headers, which apply to both requests and responses but with no relation to the transmitted data, request headers, which contain information about the client or resources to be fetched, response headers, which contains additional information about the response or the server and entity headers which carry information about the body of an entity like content length or MIME type.

Headers can additionally be grouped according to how proxies handle them. For instance, end-to-end headers must be retransmitted by intermediate proxies in their unmodified states and must be cached.

They must be transmitted to the final recipient of the message, where the recipient is either a server for a request, or a client, for a response.

On the other hand hop-to-hop headers are neither cached nor retransmitted since they are only meaningful for only a single level transport connection.

Classification of Headers By Usage

• Authentication — headers under this usage category includes: WWW-Authenticate, Authorizations, Proxy-authenticate and Proxy-Authorization
• Caching — For caching purposes, headers includes: Age, Cache-Control, Expires, Pragma and Warning.
• Client Hints — includes Accept-CH, Content-DPR, DPR, Downlink, Save-Data, Viewport-Width and Width.
• Conditionals — includes Last-Modified, ETag, If-Match, If-None-Match, If-Modified-Since and If-Unmodified-Since
• Connection Management — includes Connection and Keep-Alive
• Content Negotiation — This includes Accept, Accept-Charset, Accept-Encoding, Accept-Language
• Controls — Include Expect and Max-Forwards
• Cookies — Under this usage we have headers such as Cookie, Set-Cookie, Cookie2 and Set-Cookie2
• CORS — Here we have Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Headers, Access-Control-Allow-Methods, Access-Control-Expose Headers, Access-Control-Max-Age, Access-Control-Request-Headers, Access-Control-Request-Method and Origin to indicate where a fetch originate from
• Do Not Track — Includes DNT for expressing the user’s tracking preference and TK to indicate the tracking status applied to a corresponding request.
• Downloads — For this usage, we have Content-Disposition which is a response header if the resource transmitted should be displayed inline or handled like a normal download by the browser
• Message Body Information — Here we have Content-Length which indicates the size of the message body sent to the recipient, Content-Type which indicates the media type of the resource, Content-Encoding used to specify compression algorithm, Content-Language which describes the language preferences for the intended audience and Content-Location which indicates the alternate location for the returned data.
• Proxies — includes headers like Forwarded, X-Forwarded-For (deprecated), X-Forwarded-Host (deprecated), X-Forwarded-Proto and Via added by both forward and reverse proxies.
• Redirects — Uses the Location header which indicates the URL to redirect the page to
• Request Content — Includes From, Host, Referrer, Referrer-Policy and User-Agent.
• Response Context — Contains allow which lists the set of HTTP request methods supported by a resource and Server which contains information about the software running on the server of origin.
• Range Requests — includes If-Range, Accept-Ranges to indicate if a server supports a range request, Range which indicates the part of a document the server should return and Content-Range which indicates the exact point where in a full body message a partial message belongs.
• Security — includes Content-Security-Policy, Content-Security-Policy-Report-Only, Public-Key-Pins, Public-Key-Pins-Report-Only, Strict-Transport-Security, Upgrade-Insecure-Requests, X-Content-Type-Options, X-Frame-Options and X-XSS-Protection which activate cross site scripting filtering
• Server-sent Events — includes Ping-From, Ping-To and Last-Event-ID
• Transfer Coding — includes Transfer-Encoding which specifies the form of encoding used to safely transfer an entity to the user, TE which specifies the transfer encodings the user agent can accept and Trailer which allows a sender to append additional fields at the very end of a chunked message.
• Web Sockets — includes Sec-WebSocket-Key, Sec-WebSocket-Extensions, Sec-WebSocket-Accept, Sec-WebSocket-Protocol and Sec-WebSocket-Version

Querying HTTP Security Headers Status

You can quickly interrogate the status of the security headers using tools such as KeyCDN’s HTTP Header Check Tool.

By inputting the website URL one desires to check, this tool returns the security headers currently configured on the web application or web service.

A second way to check the status of the headers is using the browser’s inbuilt developer tools e.g. Chrome Devtools.

By navigating to the “Network” section, refreshing and selecting your desired domain, you can view the response headers.

The last way to check is using the online resource “securityheaders.io” which ranks a site with a score based on HTTP security headers present.

Implementation & Hardening of HTTP Security Headers

HTTP header implementation is largely dependent on web server platform, network edge and Content Delivery Network (CDN) providers.

As a measure of prudence and contingency, it is advised to back up any configuration files before any changes, to note that some headers are not supported by all browsers and that some configurations especially in Apache must be enabled prior to implementation.

The following is a summary on how to implement various headers on different environments:

1. X-XSS-Protection Header

Apache Server — modify the Header set X-XSS-Protection “1; mode=block” directive in Apache configurations file (httpd.conf)

Nginx — modify the directive add-header X-XSS-Protection “1; mode=block” in nginx configuration file (nginx.conf) and restart nginx to reflect changes

MaxCDN — Navigate to Edge Rules and create a new rule and select “add X-XSS-Protection Header” from the options.

Microsoft IIS — On the IIS manager, select the site you wish to enable the header for then under Http Response Headers (under actions) add an entry for a name and value

2. HTTP Strict Transport Security Header (HSTS)

Apache — Modify the Header set Strict-Transport-Security “max-age=31536000; includeSubDomains; preload” directive in httpd.conf file then restart apache

Nginx — add the add_header Strict-Transport-Security ‘max-age=31536000; includeSubDomains; preload’; directive in nginx.conf under ssl and restart nginx

Cloud Flare — On cloud flare, select the site and under the Crypto tab click “Enable HSTS”

Microsoft IIS — Under HTTP Response Headers on the IIS security manager add a name and value for the respective site as:

Name: As Preferred

Value: max-age=31536000; includeSubDomains;preload

3. X-Frame-Options (Prevents Clickjacking)

Apache — Add Header always append X-Frame-Options DENY to httpd.cof & restart

Nginx — Add add_header X-Frame-Options “DENY”; under nginx.conf and restart

WordPress — Add header(‘X-Frame-Options: DENY); to wp-config.php file

4. HTTP Public Key Pinning (MITM Attacks)

Modify browser centric configurations

5. Content Security Policy (Code Injection)

Apache — Add Header set Content-Security-Policy “default-src ‘self’;” to httpd.conf and restart

Nginx — Add add_header Content-Security-Policy “default-src ‘self’;”; to nginx.conf file

Microsoft IIS — add Name: As desired & Value: default-src ‘self’ for the respective site under HTTP Response Headers.