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

Description

max-age=SECONDS

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

includeSubDomains

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

Preload

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

X-Frame-Options

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

Description

deny

No rendering within a frame.

sameorigin

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

X-XSS-Protection

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

Description

0

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

X-Content-Type-Options

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

Description

nosniff

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

Content-Security-Policy

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.

Referrer-Policy

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

What’s up India? PixPirate is back and spreading via WhatsApp

8 min read - This blog post is the continuation of a previous blog regarding PixPirate malware. If you haven’t read the initial post, please take a couple of minutes to get caught up before diving into this content. PixPirate malware consists of two components: a downloader application and a droppee application, and both are custom-made and operated by the same fraudster group. Although the traditional role of a downloader is to install the droppee on the victim device, with PixPirate, the downloader also…

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…

Topic updates

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