Securing the HTTP Header

Throughout the following three sections this article discusses the usage of certain security related HTTP headers and their implications on the security of a web application.

  1. HTTP headers related to security
  2. HTTP headers related to cookie security
  3. HTTP headers related to information disclosure

Security related HTTP headers

Strict-Transport-Security

HTTP Strict Transport Security (HSTS) instructs the client to enforce HTTPs connections to the webapplication in question.

Parameters

max-age: the lifetime of the header in the browsers cache. if set to 0 the header is removed from the browsers cache

Examples

Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=0

X-Xss-Protection

XSS Protection instructs the client to enable the cross site scripting filter, built into most modern browsers.

Parameters

n: 0 or 1, for disabling or enabling the filter mode: with mode=block the browser is iunstructed to block pages containing xss instead of sanitizing them

Examples

X-Xss-Protection: 1; mode=block
X-Xss-Protection: 0

X-Content-Type-Options

Content Type Options instructs the client to interpret a HTTP resource as specified in the content type header. Otherwise modern browsers try to detect the content type either through the filename extension or the content.

Parameters

nosniff: the only specified value, disables content type sniffing

Examples

X-Content-Type: nosniff

X-Frame-Options

Frame Options instructs the client how it should behave in the case the webapplication is loaded inside a frame.

Parameters

deny: rendering the page in a frame is prohibited

sameorigin: rendering the page in a frame is only allowed through a page from the same origin

allow-from: allow rendering the page in a frame through pages from the given origin

Examples

X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from: example.com

Content-Security-Policy

Content Security Policy allows to specify fine grained controls for the source of every resource type (e.g. javascript, images, css, etc.).

Parameters

default-src: default source location for all resource types, used as fallback if no specific source location is specified

script-src: define the origin for scripts

object-src: define the origin for plugins

style-src: define the origin for css

img-src: define the origin for images

media-src: define the origin for video and audio

frame-src: define the origin for frames

font-src: define the origin for fonts

connect-src: define the origin for script interfaces

form-action: define the destination the forms action attribute

sandbox: define a sandbox policy

script-nonce: define a nonce which has to be present on script elements in order to execute

plugin-types: define the set of plugins that are allowed

reflected-xss: instruct the client to activate or deactivate heuristics to filter or block reflected cross-site scripting

report-uri: defines the destination for reports about policy violation

Keywords

'none': disallows the loading of the specified resource type

'self': allows the loading of the specified resource type only from the same origin

'unsafe-inline': allows the use of inline js and css

'unsafe-eval': allows the use of functions like eval()

Examples

Content-Security-Policy: default-src 'self'

Public-Key-Pins

The past has shown that not all certification authorities are as trustworthy as they should be. Multiple incidents have happened, certificates for genuine sites were issued to the wrong people or orgnizations, breaches of certification authorities' datacenters, etc. Public key pinning allows the specification of a public key's fingerprint. This way if a client reaches a certain site once, it can authenticate the webserver all by itself the next time.

Parameters

pin-sha256: a public key's fingerprint

max-age: the number of seconds a key pin can live inside the browser's cache

includeSubDomains: whether or not the pin is also valid for all subdomains

Examples

Public-Key-Pins: pin-sha256="<sha256>"; pin-sha256="<sha256>"; max-age=15768000; includeSubDomains

Cookie security related HTTP headers

Most webapplication where users are authenticated use cookies to synchronize session information between the browser and the webapplication. So the security of those cookies highly influences the security of the users' data, permissions and actions. The following lists a few flags which can be set on cookies in order to prevent cookie theft.

Secure

The Secure flag on a cookie instructs the client to only send the cookie through HTTPs. This prevents attacks on cookies using SSL stripping.

Examples

Set-Cookie: xyz=123;Secure

HttpOnly

The HttpOnly flag on a cookie instructs the browser to disallow access to the cookie through client side scripting. This prevents cookie stealing attacks using cross site scripting.

Examples

Set-Cookie: xyz=123;HttpOnly

Information disclosure related HTTP headers

Some webserver software is talky and specifies a lot of information inside HTTP Headers, e.g. webserver version, scripting language used, etc. This can simplify attacks on the webserver itself or the webapplication. The less information gets exposed here le smaller the attack surface becomes. In the following a few common HTTP Headers are listed.

Server

Most of the time the Server header discloses information about the webserver software and version or the used scripting language. A hint for the attacker, which can be safely disabled.

Examples

Server: nginx

X-Powered-By

Most of the time the X-Powered-By header discloses information about the webserver software and version or the used scripting language. A hint for the attacker, which can be safely disabled.

Examples

X-Powered-By: PHP

Comments