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
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.
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 Header Values
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.
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
Disable the protection
Protection enabled. If an XSS attack is detected, the browser will sanitize the page to stop the attack.
Protection enabled. When an XSS attack is detected, rather than sanitizing the page, the browser will prevent the page from rendering.
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 Header Values
This will prevent the browser from MIME-sniffing a response away from the declared content type.
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:
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.