Demystify HTTP Security Headers

17/02/2022 · 20 min read · cybersecurity web http https headers  ·
Share on:

Translations

Overview

In this article, I demystify the HyperText Transfer Protocol (HTTP) security response headers. The objective is to provide you with the basics in order to understand what these headers are, what they are used for, and how to use them. This article is mainly intended for Web hosts and Website developers who wish to improve the inherent security of their sites, but also for all curious individuals eager to improve their knowledge in the field of Web security. As usual, you will find the full list of sources used at the end of this article.

Introduction

The HTTP protocol is a network communication protocol for exchanging data for the Web, which constitutes all the resources available and referenced on the Internet. It is a “client-server” protocol, meaning that an element called client (a Web browser or a mobile application, for example) initiates communication requests to another element called server (software hosting Web pages) which sends responses to the client, all in a well-defined format. In these requests and responses, data and metadata stored in headers circulate, containing information to structure the exchanges. There are hundreds of possible headers, some dedicated to requests, others dedicated to responses, or both. For example, there is a header called Cookie, which is not a sweet biscuit but rather data provided by the server to the client and then used as a kind of token to authenticate a user, track them, etc. Headers either contain directly a value or directives (which can be optional) to define their characteristics with values. Note also that these headers are sometimes manipulated by elements on the network located over the transfer path between the client and the server.
Some of these headers provide security functions and I will focus here on the security headers returned by the server in its responses. They help raise the security level by mitigating the risks of exploitation of certain Web vulnerabilities.

Checking the HTTP security headers of a Website

Let’s discover these famous headers… You can use this tool to test a Website. A score between F and A+ will be provided for the tested Website with details of the values of the response headers.

https://thibautprobst.fr is ranked A+... But how to get your A+?

You can also use browser development tools (here is the example with Google Chrome) which are today more effective for this kind of analysis than packet capture software, most of the Web traffic being encrypted (although it is possible to decrypt traffic with Wireshark).

HTTP Strict Transport Security

The HTTP Strict Transport Security (HSTS) response header instructs the client that the Website is only accessible through the HTTPS protocol and not HTTP. HTTPS corresponds to the use of the Transport Layer Security (TLS) protocol to encrypt HTTP protocol data. The use of the HTTPS protocol contributes to data confidentiality (through encryption) and data integrity (through the use of certificates to authenticate the server and sometimes the client, and through the use of hashing mechanisms to verify the data integrity).
There are 2 possible directives for the HSTS header:

  • max-age (mandatory): the duration (in seconds) during which the client should consider that the Website is only accessible via HTTPS.
  • includeSubDomains (optional): indicates whether HSTS also applies to subdomains of the Website.

Example of implementation:
strict-transport-security: max-age=31536000; includeSubDomains

Example of HSTS usage

X-Frame-Options

The X-Frame-Options response header indicates whether the client is allowed to display a page within an element of the HyperText Markup Language (HTML), which describes the content of Web pages, used in the current Web page provided by the server. Such an element can be of type iframe (floating frame to embed an HTML page in the current page), object (external resource embedded in the current page), or applet (Java applet). The frame or embed elements, sometimes included, are considered obsolete.
X-Frame-Options helps prevent your Website content from being used by HTML objects in other Websites (especially transparently for the user if transparent iframes are used), which is called clickjacking.
There are 2 possible values for the X-Frame-Options header:

  • DENY: prevents the display of a page within an iframe, object, or applet element.
  • SAMEORIGIN: allows the display of a page within an iframe, object, or applet element with an origin (protocol, host, and port) that is the same as the current page. The application of this permission remains up to the Web browser regarding the level of nesting of HTML elements when multiple elements are nested.

Example of implementation:
x-frame-options: SAMEORIGIN

Example of X-Frame-Options usage with SAMEORIGIN value

X-Content-Type-Options

The X-Content-Type-Options response header prevents the client from analyzing the content of a file sent through a Web response in order to determine its type, by overriding the file type originally returned by the server in the response with the Content-Type header (which specifies the Multipurpose Internet Mail Extensions or MIME type of a file). When applied by browsers, this particularly allows a Website to avoid receiving files of an unauthorized type.
There is only one possible value for the X-Content-Type-Options header:

  • nosniff: prevents file type analysis to override it.

Example of implementation:
x-content-type-options: nosniff

Example of X-Content-Type-Options usage

X-Permitted-Cross-Domain-Policies

The X-Permitted-Cross-Domain-Policies response header controls the use of the Website content in external Flash applications or PDF documents. A file named crossdomain.xml located at the root of the Website and containing control rules can be specified in the header to be used by the client.
There are 5 possible values for the X-Frame-Options header:

  • none: prohibits any use of content.
  • master-only: only the crossdomain.xml rules file can be used.
  • by-content-type: only rule files of the type defined by the Content-Type header value text/x-cross-domain-policy are allowed. This applies to HTTP and HTTPS only.
  • by-ftp-filename: Only rule files with names crossdomain.xml are allowed. This applies to the File Transfer Protocol (FTP) protocol only.
  • all: All rule files from the Website domain are allowed.

Example of implementation:
x-permitted-cross-domain-policies: none

Example of X-Permitted-Cross-Domain-Policies usage with none value

Content-Security-Policy

The Content Security Policy (CSP) response header allows you to define a set of rules to limit the risk of Cross Site Scripting (XSS) attacks, where a client inadvertently executes malicious scripts (pointing to external domains related to an attacker) hosted by the server and injected by an attacker. With CSP, the server can indicate to the client which domains are allowed to request content from (via scripts, images, etc.).
There are 16 possible directives for the CSP header:

  • base-uri: restricts the base Uniform Resource Locators (URL, the address of a site or Web page) used to compose relative URLs in a document. If the directive is absent, the <base> element of the Web page is used. If the value is absent, all URLs are allowed.
  • child-src: indicates the allowed sources for nested browsing contexts (such as iframe). If the directive is absent, the client must use the default-src directive.
  • connect-src: indicates the allowed sources for Application Programming Interface (API, enabling dynamic and transparent content loading) within a Web page. If the directive is absent, the client must use the default-src directive.
  • font-src: indicates the allowed sources for fonts. If the directive is absent, the client must use the default-src directive.
  • media-src: indicates the allowed sources for media (audio or video). If the directive is absent, the client must use the default-src directive.
  • img-src: indicates the allowed sources for images and favicons. If the directive is absent, the client must use the default-src directive.
  • frame-src: indicates the allowed sources for nested elements such as iframe. If the directive is absent, the client must use the default-src directive.
  • object-src: indicates the allowed sources for using object or applet elements. If the directive is absent, the client must use the default-src directive.
  • script-src: indicates the allowed sources for JavaScript code. If the directive is absent, the client must use the default-src directive.
  • style-src: indicates the allowed sources for style sheets (allowing the formatting of Web pages). If the directive is absent, the client must use the default-src directive.
  • default-src: indicates the default value to use for all directives ending in “-src” when they are absent.
  • frame-ancestors: indicates the allowed sources to display a page within HTML elements used in the current Web page provided by the server: iframe, object, or applet. This directive is similar to the X-Frame-Options header (e.g., if the none value is used, it is equivalent to using the DENY value of X-Frame-Options) but offers more granularity by specifying sources.
  • plugin-types: indicates the MIME types of files allowed to be loaded by plugins (through object, embed, or applet elements).
  • form-action: indicates the allowed sources as targets for Web form submissions.
  • sandbox: indicates the use of a sandbox, controlling the execution of pop-ups, plugins, and scripts through various possible values. It also adds a same-origin constraint (see below for possible values).
  • report-uri (soon to be replaced by report-to): indicates the address to be used by the client to send a report if the directives are triggered when processing Web responses.

The values found as sources in these directives are:

  • ‘self’: the domain associated with the Website hosting the resource.
  • ’<host-source>’: the IP address or domain name (can include the protocol and a port number, as well as the value * to indicate all possible values).
  • ’<scheme-source>’: a protocol or data format.
  • ‘unsafe-eval’: the use of the JavaScript eval() function (a function that evaluates a string).
  • ‘unsafe-hashes’: a hash of a JavaScript script.
  • ‘unsafe-inline’: the use of inline resources such as scripts.
  • ’none’: no sources.

Example of implementation:
Content-Security-Policy: default-src 'self'; frame-src 'self' '*.example.com'; img-src *; form-action sandbox allow-scripts

Example of CSP usage

X-XSS-Protection

The X-XSS-Protection response header also helps limit the risk of XSS attacks. This header is redundant with CSP and not supported by most recent Web browsers but can still be useful to protect clients with older implementations. This protection uses XSS filtering mechanisms of some Web browsers like Internet Explorer’s.
There are 4 possible values for the X-XSS-Protection header:

  • 0: no XSS filtering.
  • 1: XSS filtering by removing elements of the Web page considered malicious.
  • 1; mode=block: XSS filtering and blocking of the display of the Web page.
  • 1; report=<reporting-uri>: XSS filtering by removing elements of the Web page considered malicious and indicates the address to be used by the client to send a report if XSS filtering is triggered.

Example of implementation:
X-XSS-Protection: 1; mode=block

Example of X-XSS-Protection usage

Permissions-Policy

The Permissions-Policy response header replaces the Feature-Policy header and allows you to control the advanced features that can be used in a browser within a Web page and all iframe elements within it.
The possible directives are associated with client features, and the most common ones for the Permissions-Policy header are:

  • accelerometer: control of the accelerometer.
  • ambient-light-sensor: control of ambient light.
  • autoplay: control of automatic media playback.
  • battery: control of reading battery status.
  • camera: control of camera usage.
  • display-capture: control of screen capture.
  • encrypted-media: control of using the Encrypted Media Extensions (EME) API.
  • execution-while-not-rendered: control of code execution in invisible frames.
  • execution-while-out-of-viewport: control of code execution in frames outside the visible window.
  • fullscreen: control of full-screen display.
  • gamepad: control of gamepad devices.
  • geolocation: control of geolocation usage.
  • gyroscope: control of gyroscope usage (measurement of orientation and angular velocity in space).
  • layout-animations: control of the diplay of layout animations.
  • legacy-image-formats: control of the display of legacy image formats.
  • magnetometer: control of magnetometer usage (measurement of electromagnetic field).
  • microphone: control of microphone usage.
  • midi: control of using the Musical Instrument Digital Interface (MIDI) API.
  • navigation-override: control of spatial navigation (e.g., with keyboard keys).
  • oversized-images: control of the diplay of oversized images.
  • payment: control of using the Payment Request API for easier bank payments.
  • picture-in-picture: control of playing videos in Picture in Picture mode (having a small additional window playing a video, in addition to the main one).
  • publickey-credentials-get: control of retrieving stored credentials.
  • screen-wave-lock: control of preventing screen dimming or turning off.
  • speaker: control of using speakers.
  • sync-xhr: control of using synchronous XMLHttpRequest (JavaScript interface for reading data from a URL).
  • unoptimized-images: control of the diplay of unoptimized images.
  • usb: control of accessing USB ports.
  • unsized-media: control of resizing media after the initial layout.
  • vibrate: control of vibrations.
  • wake-lock: control of preventing sleep mode.
  • Web-share: control of the sharing to external destinations (e.g., mobile apps).
  • xr-spatial-tracking: control of 3D visualization (for virtual or augmented reality).

The values found as sources in these directives are:

  • ’*’: allowed in the entire document and all its nested browsing contexts. This is the default value if the directive is not used.
  • ‘self’: allowed in the entire document and its same-origin nested browsing contexts.
  • ‘src’: allowed in an iframe if the document loaded in that iframe is of the same origin as the src attribute value of the iframe.
  • ’none’: forbidden.
  • ’<origin>’: allowed for one or more origins (separated by a space).

Example of implementation:
permissions-policy: accelerometer=(), camera=(), gamepad=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=(), vibrate=()

Example of Permissions Policy usage

Referrer-Policy

The Referrer-Policy response header allows you to control the referrer information (address of the Web page containing the requested content) sent by the client (via the Referer request header) to the new Web page being accessed. It defines if this information should be omitted, if the address should be sent in its entirety or just a part of it, and under which conditions this applies (whether the Web page is navigated through the same domain, subdomains, or an external domain).
There are 8 possible values for the Referrer-Policy header:

  • no-referrer: Referrer header is not sent.
  • no-referrer-when-downgrade: Referrer header is sent only when the security level of the protocol remains the same (HTTP to HTTP or HTTPS to HTTPS) or improves (from HTTP to HTTPS). This is the default behavior if no value is provided.
  • origin: Referrer header is sent only with the origin.
  • same-origin: Referrer header is sent only when the origin remains the same.
  • origin-when-cross-origin: Referrer header is sent when the origin remains the same, and sent only with the origin otherwise.
  • strict-origin: Referrer header is not sent when the security level of the protocol degrades (HTTPS to HTTP), and sent only with the origin otherwise.
  • strict-origin-when-cross-origin: Referrer header is sent when the origin remains the same, sent only with the origin otherwise, and if the security level of the protocol remains the same, it is not sent otherwise.
  • unsafe-url: Referrer header is sent.

Example of implementation:
Referrer-Policy: no-referrer

Example of Referrer Policy usage

Clear-Site-Data

The Clear-Site-Data response header instructs the client to clear cache, storage, and cookies before processing the received response from the server.
There are 5 possible values (which can be combined) for the Clear-Site-Data header:

  • cache: indicates the need to empty the cache.
  • cookies: indicates the need to erase cookies and authentication credentials associated with the origin (including subdomains) of the response URL.
  • storage: indicates the need to erase any local Web storage or Document Object Model (DOM) storage performed by the client.
  • executionContexts: indicates the need to reload all of the client’s browsing contexts (typically iframes, tabs, or windows).
  • *: indicates the need to clear any possible type of data.

Example of implementation:
Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"

Example of Clear-Site-Data usage

Cache-Control

The Cache-Control header allows to manage the caching policy in both requests and responses. Here, we focus on responses, as while beneficial to improve performance and reducing transfer costs (by avoiding to fetch the same data several times), controlling caching helps limit the risk of storing sensitive information. It is worth noting that in the absence of a provided cache-control mechanism, browsers resort to heuristics in order to determine the caching policy. The HTTP protocol specification recommends a cache duration equal to 10% of the time elapsed between the current date and the date of the resource last modification (obtained through the Last-Modified header).
There are 9 possible directives for the Cache-Control header in responses:

  • public: the response can be cached by any cache.
  • private: the response can only be cached by a non-shared cache (accessible only by a single user).
  • no-cache: the client must verify if the obtained data has changed on the server before using a cache (the server can then indicate with the ETag header if the data hasn’t changed without sending all the data).
  • no-store: the client cannot store data from the response.
  • no-transform: the content of the response cannot be modified by intermediaries (like proxies) along the response path.
  • must-revalidate: the client must perform a new request if the data is expired (referring to the Expires header).
  • proxy-revalidate: the client must perform a new request if the data is expired, but this does not apply to non-shared caches.
  • max-age: the response cache is valid for a given duration (in seconds), counting from the request date. This directive overrides the Expires header.
  • s-maxage: for non-shared caches only, the response cache is valid for a given duration (in seconds), counting from the request date. This directive overrides either the Expires header or the max-age directive of the Cache-Control header.
  • cache-extension: to allow extensions on caching control.

Example of implementation:
Cache-Control: public, max-age=86400

Example of Cache-Control usage

Server

The Server response header provides information about the system used by the Web server. It doesn’t offer any security function, but its usage could howerver disclose information that might be useful for an attacker looking to exploit vulnerabilities on the Web server. Therefore, it is recommended to override the value of this header with an arbitrary one.

Example of implementation:
Server: null

Cross-Origin-Resource-Policy

The Cross-Origin-Resource-Policy (CORP) response header allows you to control requests from origins different from the one associated with your website response. CORP helps limit the risk of Cross-Site Script Inclusion (XSSI) attacks where a script from a malicious and different origin is executed.
There are 3 possible values for the CORP header:

  • same-site: allows the loading of resources from the same domain (here the domain is the registered domain name, which is less specific than the origin).
  • same-origin: allows the loading of resources from the same origin (protocol, host, and port).
  • cross-origin: allows the loading of resources from any origin.

Example of implementation:
Cross-Origin-Resource-Policy: same-origin

Cross-Origin-Resource-Sharing

Cross-Origin-Resource-Sharing (CORS) is a mechanism that allows, through several response headers, to indicate to the client the authorized origins (in addition to the website origin) to load its resources, the HTTP methods and headers that can be exposed, as well as the use of authentication information or not. We can also define the validity period of preliminary requests made by the client with the HTTP OPTIONS method to obtain communication options on the targeted resource, prior to requests made for data exchange.
The headers of the CORS mechanism are:

  • Access-Control-Allow-Origin: indicates the origins (can include the value *) that are allowed.
  • Access-Control-Expose-Headers: indicates the header(s) that can be used by the client.
  • Access-Control-Max-Age: indicates the duration (in seconds) for which the result of the preliminary request can be cached.
  • Access-Control-Allow-Credentials: indicates whether the main request can or cannot be made with authentication information.
  • Access-Control-Allow-Methods: indicates the authorized method(s) to access the resource.
  • Access-Control-Allow-Headers: indicates, in a response to a preliminary request, the HTTP headers that can be used when the main request is sent.

Example of implementation:
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
Access-Control-Max-Age: 600
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET, HEAD, OPTIONS
Access-Control-Allow-Headers:

Cross-Origin-Embedder-Policy

The Cross-Origin-Embedder-Policy (COEP) response header controls the use of resources from different origins in a web page. COEP blocks the loading of these resources unless they are allowed by CORS or CORP headers. Therefore, it’s necessary to ensure that the websites hosting these external resources use these mechanisms and allow loading from different origins.
There are 2 possible values for the COEP header:

  • unsafe-corp: allows the loading of resources from different origins than the document ones, without the need to declare a CORS or CORP policy. This is the default value.
  • require-corp: allows the loading of resources from different origins only if authorized via CORS or CORP.

Example of implementation:
Cross-Origin-Embedder-Policy: require-corp

Examples of CORP, CORS, and COEP usage across different origins

Cross-Origin-Opener-Policy

The Cross-Origin-Opener-Policy (COOP) response header allows you to control the usage of browsing contexts when using resources from different origins. This helps separate trusted resources from other resources from a memory perspective on the client side. This can contribute to mitigating Spectre-type attacks.
There are 3 possible values for the COOP header:

  • unsafe-none: allows sharing browsing contexts for resources from different origins unless the resources from different origins have a COOP policy different from unsafe-none. This is the default value if no value is configured.
  • same-origin: indicates a dedicated browsing context for each different origin.
  • same-origin-allow-popups: allows sharing browsing contexts for resources from different origins where the COOP policy is not present or has the value unsafe-none.

Example of implementation:
Cross-Origin-Opener-Policy: same-origin

Example of COOP Usage

Conclusion

Response headers can enhance the security of your website if they are used correctly. They also heavily rely on good implementation on web browsers and are in constant evolution. Therefore, stay informed about the standards!
However, I hope this article has helped you demystify these headers and will assist you in implementing them more easily. If you’re still a bit unsure about the right strategy to adopt, here’s a summary of what I can recommend as a general rule of thumb:

  • Deploy your site in HTTPS, not HTTP, and use the HSTS header for all your subdomains.
  • Use the X-Frame-Options header to control the display of your pages in embedded elements: allowing only the same origins or denying it if the impact of potential clickjacking of your resources is high.
  • Supplement access control to resources from other origins with CORP, CORS, COEP, and COOP, but be vigilant about the impacts on the use of external resources by other sites and vice versa. It’s wise to test COEP in Report Only mode to assess the potential impact of its activation.
  • Maintain control over the types of files exchanged by deploying the X-Content-Type-Options header.
  • Prevent the use of your content in Flash applications or PDF documents with the X-Permitted-Cross-Domain-Policies header.
  • Restrict the domains to which you allow the loading of external content in your pages with the CSP header.
  • Enable XSS filtering in some browsers with the X-XSS-Protection header.
  • Minimize the use of advanced features on client devices of your website with the Permissions-Policy header.
  • Limit the propagation of information contained in your website URLs by activating the Referrer-Policy header. A good trade-off is to allow these propagations when the origin remains the same, to allow it with only the origin otherwise and only if the security level of the protocol remains the same, and to deny it in other cases.
  • Use the Clear-Site-Data and Cache-Control headers if you believe that storing your website data in browsers poses a risk.
  • Lastly, modify the value of the Server header not to disclose obvious information about the system hosting your website.

Keep in mind that security is a set of measures, and that only a good strategy for using response headers is not enough. Indeed, it’s important to consider other existing protection mechanisms for Web security: robust code, protection against denial of service, a Web Application Firewall, a Reverse Proxy, etc.

Sources

Translations