HTTP response headers can reinforce the security of your web applications. By just adding a few lines of code, you can leverage these headers to prevent most modern web browsers from encountering easily avoidable vulnerabilities.
With the current proliferation of cyberattacks, knowing how to use HTTP security headers can help you to seal loopholes in your applications and provide more secure user experiences.
This blog post explores how to use some HTTP headers to increase the security of your web applications.
What Are HTTP Headers?
Every time a user visits a web application using a client (usually a browser), the client sends some request headers to the server while the server responds with the requested content together with HTTP response headers. Both the client and the server use these header messages to exchange data as part of the HTTP protocol.
HTTP headers are essentially key:value pair of strings used to transfer technical information, such as the type of resource being requested, how the browser should cache content, and more.
You can examine plain-text HTTP response headers information using a simple cURL command, with the —head option. Here is an example:
By setting up suitable security headers in your web applications, you can harden them against common attacks.
HTTP Strict Transport Security (HSTS)
The HTTP Strict Transport Security (usually shortened to HSTS) is a response header that allows you to instruct browsers that interactions should only be held via secure HTTPS connections, and not via the insecure HTTP protocol.
For example, if a web application permits a connection via an http:// URL before redirecting visitors to https://, this initial interaction with the non-encrypted version of the application could create opportunities for different types of attacks, such as man-in-the-middle attacks.
With HSTS, you can declare to a web browser that it should never access an application through HTTP. Any attempts to load the web application through HTTP are automatically changed to HTTPS.
Here are the HSTS directives:
- max-age=<number of seconds>—ensures the browser accesses the application using HTTPS for the specified number of seconds.
- includeSubDomains—an optional parameter that ensures HSTS is applied even for the subdomains of the current domain.
- preload—an optional parameter used when a web app has been submitted to the HSTS preload list.
Here is an example of how you can implement HSTS:
X-Frame-Options (XFO)
The X-Frame-Options (also called XFO) is a response header that allows you to permit or forbid web browsers from rendering a page in a “frame,” “iframe,” “embed,” or “object” HTML tag.
HTML iframes enable a web application to be nested into a parent web application. Although they offer useful capabilities, an attacker could use them to embed a legitimate web application into a malicious web application. This makes the application susceptible to click-jacking attacks; that is, tricking a user into clicking a web page element that could cause them harm.
With XFO, you can inform the browser to apply restrictions that prevent your web application from being framed. This could prevent an attacker from embedding your web application into a malicious web page and tricking users into completing harmful actions.
Here are the XFO directives:
- DENY—completely blocks iframes.
- SAMEORIGIN—allows iframes only for applications on the same domain.
Here is an example:
Content Security Policy (CSP)
The Content Security Policy (usually shortened to CSP) is a response header that allows you to control the type of resources that web browsers can load for your web app. It’s a powerful way of explicitly whitelisting your application’s content sources.
With CSP, you can guard your web application against malicious execution of nefarious content—such as from cross-site scripting (XSS), click-jacking, or other types of code injection attacks.
Here are some common CSP directives:
- default-src <source>—acts as a fallback for fetch directives. For example, default-src ‘self’ loads every asset from the current domain.
- script-src <source>—specifies permitted sources for scripts. For example, script-src myjsscript.com loads scripts only from the specified site.
- img-src <source>—specifies permitted sources for images and favicons. For example, img-src * permits images to be loaded from any online source.
Here is an example:
X-Content-Type-Options
The X-Content-Type-Options is a response header that allows you to safeguard against content-type sniffing vulnerabilities, or MIME sniffing vulnerabilities.
MIME sniffing is a feature that most web browsers use to inspect (and fix) the content type of the resource being loaded. For example, a browser can be requested to render an image at /my-best-image.png, but the server has not set the correct type when serving it to the browser (such as Content-Type: text/plain).
The browser will then “sniff” the file to detect its file format. In such a case, the web browser will ignore the Content-Type header sent by the server and interpret the file according to the identified format. This will ensure the image is displayed properly.
While MIME sniffing is a useful browser feature, it could lead to a serious security vulnerability. For example, if a web application allows users to upload their own images, a visitor could upload an image file containing malicious HTML code to the web application. In such a case, the browser will disregard the stated image content type, and rather than rendering the image, it will execute the dangerous code.
With X-Content-Type-Options, you can instruct the browser to avoid sniffing when processing fetched resources. The browser will respect the value set in the Content-Type header.
It has only one directive:
- nosniff—prevents MIME type sniffing attempts.
Here is an example:
Clear-Site-Data
The Clear-Site-Data is a response header that allows you to instruct the browser to avoid storing the web application’s sensitive information.
You can use it to remove all the browsing data—such as cache, storage, and cookies—associated with your web app. For example, once a user logs out, you can use this header to ensure that all their stored data on the client side are deleted.
Here are the Clear-Site-Data directives:
- cache—removes all locally cached content.
- storage—removes all content stored in the DOM.
- cookies—removes all cookies.
- * (wildcard)—removes all types of browsing data.
Here is an example:
Conclusion
Most modern web browsers support several types of HTTP headers. You can leverage them to enhance the security of your web applications. By correctly configuring the headers, you can harden your defenses and safeguard against common attacks.
In this article, we reviewed the popular ones you can use to take the security of your web applications to the next level. We hope that you’ll find them useful.
