The world is becoming more interconnected every day, and online services like social media and e-commerce are contributing to massive troves of sensitive business and personal data. These developments introduce new risks and vulnerabilities for cybercriminals to exploit via cross-site scripting (XSS), man-in-the-middle (MitM) attacks, clickjacking, cross-site request forgery and other threat vectors.

With this in mind, application development teams should consider security from the outset when designing and building web applications. They can start by following guidelines, such as the SANS Institute’s “Framework for Secure Application Design and Development,” “Security in Development: The IBM Secure Engineering Framework,” Open Web Application Security Project (OWASP) Top 10,” as well as “Top 25 Most Dangerous Software Errors” from the SANS Institute and Common Weakness Enumeration (CWE).

These frameworks address many challenges associated with securing web applications. For our purposes, we’ll focus on security-related HTTP response headers, which are designed to restrict modern browsers from encountering vulnerabilities. Adopt these best practices to provide a layer of security to help users mitigate certain types of attacks and vulnerabilities.

The OWASP Secure Headers Project aims to set security parameters related to HTTP response headers that balance usability and security. Below are some of the most prominent headers users can set to bolster the security of their web applications.

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is an HTTP response header that mandates that web browsers or compatible agents should only interact with applications using HTTPS connections — and never plain HTTP or lower version of Transport Layer Security (TLS). The application server implements an HSTS policy by supplying the header “Strict-Transport-Security” over an HTTPS connection. Setting this HSTS header can help protect applications against protocol downgrade attacks, such as Poodle.

The following is an example of an HSTS header:

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

HSTS Header Values

Header Value



The time, in seconds, the browser should remember that a site is only to be accessed using HTTPS.


If this optional parameter is specified, this rule also applies to all of the site’s subdomains.


Chrome’s HSTS preload list.
Scroll to view full table


The X-Frame-Options response header protects web applications against clickjacking attacks. The application server sets the X-Frame-Options header policy in the client browser to allow or deny rendering of the web content in the frames of third-party websites.

The following is an example of an X-Frame-Options header:

X-Frame-Options: deny

X-Frame Options Header Values

Header Value



No rendering within a frame.


No rendering if the origin doesn’t match.

allow-from: <DOMAIN list>

Allows rendering in frames loaded from a specified DOMAIN.
Scroll to view full table


The X-XSS-Protection header is designed to defend web applications against reflective XSS attacks. The application server sets this header in the client browser with proper values to disable the protection or to sanitize or block reflective XSS attacks.

The following is an example of an X-XSS-Protection header:

X-XSS-Protection: 1; mode=block

X-XSS-Protection Header Values

Header Value



Disable the protection

1 Protection enabled. If an XSS attack is detected, the browser will sanitize the page to stop the attack.

1; mode=block

Protection enabled. When an XSS attack is detected, rather than sanitizing the page, the browser will prevent the page from rendering.
Scroll to view full table


When the application server sets the X-Content-Type-Options header to “nosniff” in the client browser, the script and stylesheet elements will reject responses with incorrect Multipurpose Internet Mail Extensions (MIME) types, thus limiting exposure to downloads and the risk of uploaded content that could be treated as executable or dynamic HTML files. This HTTP security header helps to prevent attacks based on MIME type confusion.

The following is an example of an X-Content-Type-Options header:

X-Content-Type-Options: nosniff

X-Content-Type-Options Header Values

Header Value



This will prevent the browser from MIME-sniffing a response away from the declared content type.
Scroll to view full table


The Content-Security-Policy (CSP) header provides defense in depth against content injection attacks, such as XSS and clickjacking. This header provides a standard method for websites to establish trust and determine the origins of content the browser is allowed to load on the webpage. CSP requires careful tuning and precise definition of the policy.

The following is an example of a CSP header:

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

Refer to Mozilla’s MDN Web Docs for more detailed information on values that can be set in a CSP header.


The Referrer-Policy HTTP response header governs what domain information sent in the referrer header should be included with requests.

The following is an example of a Referrer-Policy header:

Referrer-Policy: no-referrer

MDN Web Docs provides more information about values associated with the Referrer-Policy header.

Building Security Into the Future With HTTP Response Headers

It’s important to note that not every security-related HTTP response header is compatible with every browser. OWASP offers a helpful breakdown of which browsers support which headers.

With threats such as XSS, MitM and clickjacking growing more advanced as the cybercrime landscape evolves, application developers need to pull out all the stops to stay ahead of the curve. By implementing HTTP response headers, developers can protect against the specific attacks outlined above and ensure security is built into their software from the outset.

More from Application Security

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023

Deployment of backdoors was the number one action on objective taken by threat actors last year, according to the 2023 IBM Security X-Force Threat Intelligence Index — a comprehensive analysis of our research data collected throughout the year. Backdoor access is now among the hottest commodities on the dark web and can sell for thousands of dollars, compared to credit card data — which can go for as low as $10. On the dark web — a veritable eBay for…

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

Detecting the Undetected: The Risk to Your Info

IBM’s Advanced Threat Detection and Response Team (ATDR) has seen an increase in the malware family known as information stealers in the wild over the past year. Info stealers are malware with the capability of scanning for and exfiltrating data and credentials from your device. When executed, they begin scanning for and copying various directories that usually contain some sort of sensitive information or credentials including web and login data from Chrome, Firefox, and Microsoft Edge. In other instances, they…