Using security-related headers to secure your application against common attacks

One Paragraph Explainer

There are security-related headers used to secure your application further. The most important headers are listed below. You can also visit the sites linked at the bottom of this page to get more information on this topic. You can easily set these headers using the Helmet module for express (Helmet for koa).

Table of Contents

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a web security policy mechanism to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol. The HSTS policy is implemented by using the Strict-Transport-Security header over an existing HTTPS connection.

The Strict-Transport-Security Header accepts a max-age value in seconds, to notify the browser how long it should access the site using HTTPS only, and an includeSubDomains value to apply the Strict Transport Security rule to all of the site’s subdomains.

Header Example - HSTS Policy enabled for one week, include subdomains

  1. Strict-Transport-Security: max-age=2592000; includeSubDomains

Read on OWASP Secure Headers Project

Read on MDN web docs

Public Key Pinning for HTTP (HPKP)

HTTP Public Key Pinning (HPKP) is a security mechanism allowing HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent SSL/TLS certificates.

The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use one or more of those public keys in its certificate chain. Using this feature carefully, you can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false authentication problems for your application’s users without incurring undue risk.

Before implementing you should have a look at the Expect-CT header first, due to its advanced flexibility for recovery from misconfiguration and other advantages.

The Public-Key-Pins header accepts 4 values, a pin-sha256 value for adding the certificate public key, hashed using the SHA256 algorithm, which can be added multiple times for different public keys, a max-age value to tell the browser how long it should apply the rule, an includeSubDomains value to apply this rule to all subdomains and a report-uri value to report pin validation failures to the given URL.

Header Example - HPKP Policy enabled for one week, include subdomains , report failures to an example URL and allow two public keys

  1. Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=2592000; includeSubDomains

Read on OWASP Secure Headers Project

Read on MDN web docs

X-Frame-Options

The X-Frame-Options header secures the application against Clickjacking attacks by declaring a policy whether your application may be embedded on other (external) pages using frames.

X-Frame-Options allows 3 parameters, a deny parameter to disallow embedding the resource in general, a sameorigin parameter to allow embedding the resource on the same host/origin and an allow-from parameter to specify a host where embedding of the resource is allowed.

Header Example - Deny embedding of your application

  1. X-Frame-Options: deny

Read on OWASP Secure Headers Project

Read on MDN web docs

X-XSS-Protection

This header enables the Cross-site scripting) filter in your browser.

It accepts 4 parameters, 0 for disabling the filter, 1 for enabling the filter and enable automatic sanitization of the page, mode=block to enable the filter and prevent the page from rendering if a XSS attack is detected (this parameter has to be added to 1 using a semicolon, and report=<domainToReport> to report the violation (this parameter has to be added to 1).

Header Example - Enable XSS Protection and report violations to example URL

  1. X-XSS-Protection: 1; report=http://example.com/xss-report

Read on OWASP Secure Headers Project

Read on OWASP Secure Headers Project

X-Content-Type-Options

Setting this header will prevent the browser from interpreting files as something else than declared by the content type in the HTTP headers.

Header Example - Disallow Content sniffing

  1. X-Content-Type-Options: nosniff

Read on OWASP Secure Headers Project

Read on MDN web docs

Referrer-Policy

The Referrer-Policy HTTP header governs which referrer information, sent in the Referer header, should be included with requests made.

It allows 8 parameters, a no-referrer parameter to remove the Referer header completely, a no-referrer-when-downgrade to remove the Referer header when downgraded for example HTTPS -> HTTP, an origin parameter to send the host origin (the host root) as referrer only, an origin-when-cross-origin parameter to send a full origin URL when staying on the same origin and send the host origin only when otherwise, a same-origin parameter to send referrer information only for same-site origins and omit on cross-origin requests, a strict-origin parameter to keep the Referer header only on the same security-level (HTTPS -> HTTPS) and omit it on a less secure destination, a strict-origin-when-cross-origin parameter to send the full referrer URL to a same-origin destination, the origin only to a cross-origin destination on the same security level and no referrer on a less secure cross-origin destination, and an unsafe-url parameter to send the full referrer to same-origin or cross-origin destinations.

Header Example - Remove the Referer header completely

  1. Referrer-Policy: no-referrer

Read on OWASP Secure Headers Project

Read on MDN web docs

Expect-CT

The Expect-CT header is used by a server to indicate that browsers should evaluate connections to the host emitting the header for Certificate Transparency compliance.

This header accepts 3 parameters, a report-uri parameter to supply a URL to report Expect-CT failures to, a enforce parameter to signal the browser that Certificate Transparency should be enforced (rather than only reported) and refuse future connections violating the Certificate Transparency, and a max-age parameter to specify the number of seconds the browser regard the host as a known Expect-CT host.

Header Example - Enforce Certificate Transparency for a week and report to example URL

  1. Expect-CT: max-age=2592000, enforce, report-uri="https://example.com/report-cert-transparency"

Read on OWASP Secure Headers Project

Content-Security-Policy

The HTTP Content-Security-Policy response header allows to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (XSS)).

Header Example - Enable CSP and only execute scripts from the same origin

  1. Content-Security-Policy: script-src 'self'

There are many policies enabled with Content-Security-Policy that can be found on the sites linked below.

Read on OWASP Secure Headers Project

Read on MDN web docs

Additional resources

OWASP Secure Headers Project

Node.js Security Checklist (RisingStack)