March 23, 2018 By Madhusudhan Rajappa 3 min read

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

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Audio-jacking: Using generative AI to distort live audio transactions

7 min read - The rise of generative AI, including text-to-image, text-to-speech and large language models (LLMs), has significantly changed our work and personal lives. While these advancements offer many benefits, they have also presented new challenges and risks. Specifically, there has been an increase in threat actors who attempt to exploit large language models to create phishing emails and use generative AI, like fake voices, to scam people. We recently published research showcasing how adversaries could hypnotize LLMs to serve nefarious purposes simply…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today