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.
- HTTP headers related to security
- HTTP headers related to cookie security
- 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