In a recent interview with Security Weekly, Invicti security researcher Sven Morgenroth gave an overview of HTTP security headers. Many HTTP headers that can strengthen online application security and defend against cross-site scripting, clickjacking, and other typical threats are supported by contemporary browsers.

What are HTTP Security Headers?

A web client (often a browser) and a server exchange HTTP security headers, a subset of HTTP headers, to indicate the security-related specifics of HTTP communication. HTTP security headers can also include some headers that are only loosely connected to privacy and security. You may increase the resistance of your online application against several common assaults, such as cross-site scripting (XSS) and clickjacking, by enabling appropriate headers in web apps and web server settings. For a thorough description of the available headers, see our whitepaper on HTTP security headers.

How HTTP Security Headers Can Improve Web Application Security

Especially on this blog, when we discuss web application security, we typically imply identifying exploitable flaws and addressing them in the application code. When a web application is active, HTTP security headers add an additional layer of protection by limiting the actions that the browser and server are permitted to take. A best-practice application setup frequently depends on implementing the appropriate headers, but how do you determine which ones to use?

HTTP headers change over time depending on the support offered by browser vendors, just like other web technologies. Headers that were widely supported a few years ago, particularly in the area of security, can already be deprecated. At the same time, brand-new ideas can become accepted by everyone in a couple of months. It’s difficult to keep up with all these changes. checks for the existence and accuracy of numerous HTTP security headers and offers comprehensive explanations and recommendations to assist you in making your implementation decision.

Headers for HTTP Security That Are Most Important

Let’s start with a quick rundown of some of the most well-known HTTP response headers before moving on to an overview of other headers.

Strict-Transport-Security

HTTP Strict Transport Security (HSTS) mandates the usage of encrypted HTTPS connections rather than plain-text HTTP communication when it is enabled on the server. An example of a HSTS header would be:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

This would alert the web browser that is accessing the site that it should only use HTTPS for the next two years (including subdomains) (the max-age value in seconds). The presence of the site on a global list of HTTPS-only websites is indicated by the preload directive. Preloading aims to reduce loading times for pages and the chance of man-in-the-middle (MITM) attacks when a site is initially viewed.

Content-Security-Policy

The best strategy to defend your websites and applications from XSS attacks is to use the Content Security Policy (CSP) header, which is referred regarded as the Swiss Army knife of HTTP security headers. You may finely manage the number of approved content sources as well as many other settings. The following is a standard CSP header to accept only assets of a local origin:

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

Other directives include script-src, style-src, and img-src to specify permitted sources for scripts, CSS stylesheets, and images. For example, specifying script-src 'self' would only allow scripts from the local origin. You can also restrict plugin sources using plugin-types (unsupported in Firefox) or object-src.

X-Frame-Options

This header was first implemented in Microsoft Internet Explorer to offer defense against attacks using HTML iframes and cross-site scripting. You would use: to stop the current page from loading into any iframes.

X-Frame-Options: deny

Other acceptable values include sameorigin, which permits loading into iframes of the same origin, and allow-from, which designates particular URLs. Typically, appropriate CSP directives can be used in place of this header.

HTTP Security Headers That Are Outdated

As a temporary remedy for some security vulnerabilities, several headers were added. These become outmoded as web technology advances, frequently after only a few years of browser support. Here are simply two instances of deprecated headers that were meant to fix particular flaws.

X-XSS-Protection

As the name implies, the X-XSS-Protection Cross-site scripting assaults utilizing JavaScript injection were the reason why header was created. Usual syntax was as follows:

X-XSS-Protection: 1; mode=block

This non-standard header gave XSS filtering functionality control to browsers with XSS protection. Because XSS screening is no longer used by newer browsers, the header is no longer recommended because it was very simple to circumvent or exploit.

Public-Key-Pins

In order to stop certificate spoofing, Google Chrome and Firefox developed HTTP Public Key Pinning (HPKP). In a complex method, the server provided the web client with cryptographic hashes of valid certificate public keys in preparation for upcoming communications. An example of a header would be:

Public-Key-Pins:
    pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; 
    max-age=5184000

Public key pinning proved to be too challenging to use in reality. If the header is configured incorrectly, access to the website could be fully disabled for the duration of the maxage value (2 months in this example). In lieu of certificate transparency logs, the feature was deprecated; for more information, see the Expect-CT header below.

Other Useful HTTP Security Headers

The headers below can also assist you in hardening your online application, albeit they are not as essential as CSP and HSTS.

Expect-CT

The Expect-CT header can be used to specify that only new certificates added to Certificate Transparency logs should be accepted in order to prevent website certificate spoofing. An example of a header would be:

Expect-CT: max-age=86400, enforce, 
    report-uri="https://example.com/report"

Clients are told to block connections that go against the Certificate Transparency policy with the enforce directive. The report-uri directive, which is optional, designates a site for reporting errors.

X-Content-Type-Options

This header requires web browsers to adhere exactly to the MIME types defined in Content-Type headers when it appears in server responses. By doing this, websites are shielded from cross-site scripting attacks that utilize MIME sniffing to deliver malicious code disguising itself as a non-executable MIME type. There is only one directive in the header:

X-Content-Type-Options: nosniff

Fetch Metadata Headers

The browser can now tell the server information about certain HTTP request properties using a new set of client-side headers. There are presently four headers:

• Sec-Fetch-Site: Shows how the initiator and target origin are supposed to be related.
• Sec-Fetch-Mode: The intended request mode is indicated.
• Sec-Fetch-User: Determines whether the user initiated the request.
• Sec-Fetch-Dest: Identifies the location of the requested action.

These headers can be used to tell the server about expected application activities and spot suspicious requests if they are supported by both the server and the browser.

HTTP Headers to Enhance Security and Privacy

The last few items can be used to increase security and privacy but are not strictly HTTP security headers.

Referrer-Policy

determines if and how much referrer data should be made available to the web server. Usage examples would be:

Referrer-Policy: origin-when-cross-origin

Only same-origin requests will receive this header’s full referrer information, which includes the URL. Only origin-related information is sent in response to all other requests.

Cache-Control

You can manage the caching of particular web pages using this header. Although there are several directives, the following is the usual usage:

Cache-Control: no-store

This inhibits any server response caching, which can be important for making sure that private information is not stored in any caches. There are more directives available for cache control that is more accurate.

Clear-Site-Data

You can set the Clear-Site-Data header to ensure that private data from a website is not retained by the browser once the user signs out, for instance:

Clear-Site-Data: "*"

This will remove all browsing information from the website. For more precise control over what is cleared, use the cache, cookie, and storage directives.

Feature-Policy

You can restrict access to particular browser capabilities and APIs for the current page using this experimental header. This has the potential to manage program functioning while simultaneously enhancing security and privacy. For instance, you would submit the following header to ensure that an application cannot utilize the microphone and camera APIs:

Feature-Policy: microphone 'none'; camera 'none'

Keep Track of Your HTTP Security Headers with Invicti

Using the latest recent headers is always a good idea because HTTP security headers are frequently a simple method to increase web application security without modifying the program itself. However, it can be challenging to stay on top of things when working with hundreds of websites because vendor support for HTTP headers can change so frequently.

Invicti’s vulnerability checks test for suggested HTTP security headers in order to keep you secure and up to date. Invicti verifies that the header is present and properly configured and offers simple advice to guarantee that your web applications are always protected to the highest level.