Strengthen Your Web Applications with HTTP Security Headers | Acunetix

What is a HTTP security header?

An HTTP security header is a response header that helps protect web applications by providing browsers with specific instructions on how to handle website content securely. These headers play a crucial role in mitigating various cyber threats, such as cross-site scripting (XSS), clickjacking, and data injection attacks. By configuring HTTP security headers correctly, organizations can enforce stricter security policies, restrict unauthorized resource loading, and reduce the risk of malicious exploitation. Common HTTP security headers include Content Security Policy (CSP) to prevent injection attacks, Strict-Transport-Security (HSTS) to enforce secure HTTPS connections, and X-Frame-Options to prevent clickjacking. Implementing these headers is a fundamental and effective way to enhance web application security, providing an additional layer of defense against cyber threats.

Enhancing Your Web Application’s Security with HTTP Security Headers

In web application security testing, vulnerabilities are typically seen as exploitable weaknesses within the application’s code that must be addressed at the source. This often results in fixing a single flaw within a specific application, usually confined to one area of the code.

However, HTTP security headers function at the runtime level, offering a broader and more dynamic layer of protection. By defining strict rules for browser and server interactions once the application is live, these headers help prevent entire categories of cyber threats, making them a highly effective security measure. Properly configuring and implementing these headers is a key component of a strong security posture. The challenge lies in selecting the most impactful headers and ensuring they are consistently applied and tested across your application environment to maintain both security and functionality.

Maintaining the effectiveness of your HTTP security headers through dynamic application security testing (DAST).

Like many other web technologies, HTTP protocol headers evolve over time, influenced by changing specifications and browser vendor support. Security research often advances faster than official standards, leading to the rise and fall of de facto security practices independent of formal specifications. Headers that were once widely adopted may become obsolete, replaced by newer, more effective alternatives—making it challenging to stay up to date.

Additionally, security headers can be configured at both the server level and within the application itself. In complex environments with hundreds of servers powering thousands of websites, applications, and APIs, manually managing and auditing security headers across all touchpoints is impractical. This is where automated vulnerability scanners come into play. Advanced tools, such as Invicti’s DAST solutions, can automatically detect the presence and proper configuration of HTTP security headers, offering clear recommendations based on the latest security best practices.

 

Essential HTTP Security Headers

To start, let’s look at two of the most widely recognized HTTP response headers that every modern web application should implement. Beyond significantly reducing the risk of entire categories of web-based attacks, these headers have become a fundamental necessity for maintaining a secure online presence.

Strict-Transport-Security (HSTS)

The HTTP Strict Transport Security (HSTS) header is a crucial security measure that ensures web applications only use encrypted HTTPS connections, preventing unencrypted HTTP communication. Configured at the server level, HSTS helps protect against man-in-the-middle (MITM) attacks and protocol downgrade attempts.

A typical HSTS header might look like this:

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

This directive tells web browsers that the site, along with all its subdomains, must only be accessed over HTTPS for the next two years (as specified by the max-age value in seconds). The preload directive signifies that the site is included in a global list of HTTPS-only domains, further enhancing security by eliminating the risk of an initial unencrypted connection. Additionally, preloading improves performance by ensuring browsers never attempt to connect via HTTP, even on a first visit.

Content Security Policy (CSP)

The Content Security Policy (CSP) header is one of the most versatile and powerful HTTP security headers, providing granular control over the sources from which a web application can load content. By defining strict rules for permitted content sources—including scripts, styles, images, and other resources—CSP serves as an effective defense against cross-site scripting (XSS) attacks and other code injection threats.

A basic CSP header that restricts all resources to the same origin looks like this:

Content-Security-Policy: default-src ‘self’

Beyond this default setting, CSP allows more specific directives, such as script-src, style-src, object-src, and img-src, to define trusted sources for JavaScript, CSS, embedded objects, and images, respectively. For instance, setting script-src ‘self’ ensures that only scripts hosted on the same origin can execute, while still permitting other resources to be loaded externally. Properly implementing CSP significantly reduces the risk of unauthorized script execution and strengthens a web application’s overall security posture.

Additional HTTP Security Headers

While Content Security Policy (CSP) and Strict-Transport-Security (HSTS) are among the most essential security headers, several other HTTP headers can further enhance your web application’s defenses with minimal effort. Although they may not be as critical, these headers provide valuable protection against various web-based threats, often achieving security enhancements that would be much more complex to implement solely through application code.

X-Content-Type-Options

The X-Content-Type-Options header enhances security by preventing web browsers from “sniffing” MIME types and incorrectly interpreting files as executable scripts. When included in server responses, this header ensures that browsers strictly adhere to the MIME types declared in the Content-Type header, reducing the risk of attacks that exploit MIME sniffing to execute malicious code.

To enforce this protection, the header uses a single directive:

X-Content-Type-Options: nosniff

By implementing this header, websites can mitigate the risk of certain cross-site scripting (XSS) and drive-by download attacks, ensuring that content is processed only as intended by the server.

Cross-Origin Resource Sharing (CORS) Headers

Modern web applications often need to interact with external resources beyond their own domain, requiring controlled exceptions to the same-origin policy (SOP) enforced by browsers. Several HTTP headers allow developers to selectively relax these restrictions while maintaining strong security measures.

• Access-Control-Allow-Origin: Defines which domains are permitted to access resources across origins. The value can be a specific domain, multiple domains, or * to allow all origins (though using * should be done cautiously).
• Cross-Origin-Opener-Policy (COOP): Determines whether a top-level document can share its browsing context with cross-origin pages. Setting it to same-origin prevents unauthorized cross-origin access.
• Cross-Origin-Resource-Policy (CORP): Specifies which domains can load a particular resource. Using same-site restricts access to the same origin, preventing external sites from including the resource.
• Cross-Origin-Embedder-Policy (COEP): Similar to CORP but specifically governs embedded content. The require-corp directive ensures that only resources from permitted origins, as defined by the CORP header, can be embedded.

Since security headers often overlap in functionality, multiple configurations may be required to achieve the desired security posture while maintaining necessary cross-origin functionality. Properly implementing CORS headers ensures a balance between security and interoperability for web applications interacting with third-party resources.

Fetch Metadata Headers

Fetch metadata headers are a newer set of client-side HTTP headers that provide additional context about how a request was initiated, allowing servers to enforce stricter security policies. These headers help browsers communicate application-specific request attributes to the server, improving protection against cross-site request forgery (CSRF), cross-origin attacks, and speculative execution threats.

The four key fetch metadata headers include:

• Sec-Fetch-Site: Indicates the relationship between the request’s initiator and the target origin (e.g., same-origin, cross-site, same-site).
• Sec-Fetch-Mode: Specifies the request mode, such as cors, navigate, or no-cors, helping the server determine how the request was made.
• Sec-Fetch-User: Identifies whether the request was triggered by a user interaction, such as clicking a link.
• Sec-Fetch-Dest: Defines the intended request destination, such as document, image, script, or style.

When both the browser and server support these headers, they offer an additional layer of security by enabling the server to validate request behavior and block potentially malicious activity. Properly configured, fetch metadata headers enhance web application security by allowing finer control over how resources are accessed and used.

Additional HTTP Headers for Privacy and Security

While not strictly classified as security headers, certain HTTP headers play a crucial role in enhancing data privacy and security by controlling how information is shared between web pages and servers. One such header is Referrer-Policy, which helps regulate how much referrer information is exposed during HTTP requests.

Referrer-Policy

This header determines how much of the referring URL a browser should include when making requests to another web server. A commonly used directive is:

Referrer-Policy: origin-when-cross-origin

With this setting, the browser sends the full referrer URL when navigating within the same origin but limits it to just the origin (domain) when making cross-origin requests. This approach helps protect user privacy by preventing external sites from accessing full browsing paths while still allowing useful referrer data within the same site.

By implementing Referrer-Policy, websites can strike a balance between maintaining analytics functionality and reducing the risk of leaking sensitive URL parameters to external domains.

Cache-Control: Managing Web Page Caching

The Cache-Control header provides fine-grained control over how web pages and resources are cached by browsers and intermediary servers. Properly configuring this header is essential for performance optimization and data security, ensuring that sensitive information is not inadvertently stored or retrieved from cache.

A commonly used directive for preventing caching is:

Cache-Control: no-store

This setting ensures that the response is never stored in any cache, which is particularly useful for pages handling confidential data such as login sessions, financial transactions, or personal information.

Other Cache-Control directives allow further customization, such as setting expiration times (max-age), requiring revalidation (must-revalidate), or specifying caching behavior for private versus shared caches. By leveraging Cache-Control, websites can enhance security while optimizing content delivery based on their specific needs.

Clear-Site-Data: Ensuring User Privacy After Logout

The Clear-Site-Data header helps enhance security and privacy by instructing the browser to clear specific types of stored data when a user logs out or when a session ends. This prevents confidential information from lingering in the browser, reducing the risk of unauthorized access.

A common implementation that clears all stored site data is:

Clear-Site-Data: “*”

This directive wipes all cached content, cookies, and stored session data associated with the site. Alternatively, more specific directives such as cache, cookies, and storage allow finer control over which types of data are removed.

While not yet universally supported across all browsers, Clear-Site-Data is a valuable tool for reinforcing user privacy, especially in applications handling sensitive information like financial services, healthcare, or authentication-based platforms.

Permissions-Policy: Controlling Access to Browser Features

Formerly known as Feature-Policy, the Permissions-Policy header enables developers to restrict or allow access to various browser features and APIs for a web page. While it can be used to control application functionality, its primary purpose is to enhance privacy and security by limiting access to sensitive resources such as the microphone, camera, and geolocation.

To block all three of these features, you can use:

Permissions-Policy: microphone=(), camera=(), geolocation=()

This configuration explicitly disables access to the microphone, camera, and geolocation APIs, preventing unauthorized use by scripts or embedded content. Additional directives allow for more granular control, such as restricting access to specific domains or allowing features only in certain contexts.

By implementing Permissions-Policy, websites can reduce the attack surface, mitigate privacy risks, and ensure that only necessary features are available to users.

Deprecated HTTP Security Headers: A Look at the Past

In the early days of web security, dominant browsers frequently introduced new HTTP headers as temporary fixes for emerging threats. However, as web security standards evolved and became more structured, many of these headers were deprecated—sometimes within just a few years. While they are no longer recommended for modern applications, these deprecated headers offer valuable insight into the rapid evolution of web security technologies.

(Deprecated) X-Frame-Options

Originally introduced in 2008 by Microsoft Internet Explorer, the X-Frame-Options header was designed to prevent cross-site scripting (XSS) attacks involving HTML iframes. Before the introduction of more standardized security mechanisms, this header provided a way to control whether a web page could be embedded within an iframe, helping mitigate clickjacking attacks.

To block iframe embedding entirely, a site could use:

X-Frame-Options: deny

Alternatively, setting it to sameorigin allowed the page to be loaded in an iframe only if the parent frame was from the same origin:

X-Frame-Options: sameorigin

There was also an allow-from directive, which permitted specific trusted URLs to embed the page. However, this header was eventually deprecated in favor of the frame-ancestors directive within the Content Security Policy (CSP) standard, which provides more granular and flexible control over iframe embedding.

While deprecated, X-Frame-Options played a crucial role in the development of modern web security practices, demonstrating how quickly security strategies must adapt to evolving threats.

Deprecated HTTP Security Headers: Lessons from the Past

Over the years, various HTTP security headers have been introduced as temporary fixes for evolving security threats. However, as web security standards improved and better solutions emerged, many of these headers became obsolete. Below are three notable security headers that have since been deprecated and replaced with more effective alternatives.

(Deprecated) X-XSS-Protection

The X-XSS-Protection header was originally designed to mitigate cross-site scripting (XSS) attacks by leveraging built-in XSS filters in web browsers. A typical implementation looked like this:

X-XSS-Protection: 1; mode=block

This setting instructed the browser to detect and block suspected JavaScript injection attacks. However, due to advancements in Content Security Policy (CSP) and the increasing ability of attackers to bypass XSS filters, modern browsers have removed support for this header. Today, CSP directives serve as the primary defense against XSS attacks, rendering X-XSS-Protection obsolete.

(Deprecated) Public-Key-Pins (HPKP)

HTTP Public Key Pinning (HPKP) was introduced to prevent certificate spoofing by allowing websites to specify which cryptographic keys should be trusted in future HTTPS connections. The server would provide a hash of valid certificate public keys, as seen in this example:

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

While HPKP aimed to strengthen security, it proved overly complex and risky—a misconfiguration could lock users out of a website for extended periods (e.g., two months, as defined by max-age). Due to these challenges, HPKP was deprecated in favor of Certificate Transparency (CT) logs and the Expect-CT header—though that solution didn’t last either.

(Deprecated) Expect-CT

Following the deprecation of HPKP, the Expect-CT header was introduced as a way to enforce Certificate Transparency (CT) compliance. This header instructed browsers to only accept certificates that were logged in public CT records, preventing certificate spoofing. A typical configuration looked like this:

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

The enforce directive blocked non-compliant certificates, while report-uri allowed failures to be logged for further analysis. However, the industry eventually moved away from Expect-CT, and Mozilla now recommends disabling it entirely. Modern browsers now rely on automatic enforcement of Certificate Transparency without requiring a dedicated security header.

The Takeaway

While X-XSS-Protection, HPKP, and Expect-CT were once seen as valuable security measures, they ultimately proved ineffective or were replaced by more robust alternatives like CSP and Certificate Transparency logs. These deprecations highlight the constant evolution of web security, emphasizing the importance of staying updated with modern security best practices.

Stay on Top of HTTP Security Headers with Invicti

Implementing HTTP security headers is one of the simplest yet most effective ways to strengthen web application security, often requiring little to no changes to the application itself. However, keeping up with evolving security best practices and browser support changes can be challenging—especially when managing a large number of websites.

To help organizations maintain strong security postures, Invicti offers automated vulnerability scanning that includes thorough checks for HTTP security headers and other misconfigurations. Invicti not only detects the presence of security headers but also verifies their correct implementation, providing clear recommendations to ensure your web applications remain fully protected against emerging threats. By integrating Invicti’s security testing, businesses can effortlessly stay up to date and maintain a robust security framework.