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

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

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

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

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.