How to use HTTP Headers to secure your web applications

Response HTTP headers can strengthen the security of your web applications. With just a few more lines of code, you’ll take advantage of these headers to prevent most modern web browsers from encountering easily avoidable vulnerabilities.

With the proliferation of cyberattacks today, knowing how to use secure HTTP headers can help you fix vulnerabilities in your applications and provide a more secure user experience.

Every time a user accesses the web application with a client (usually a browser), the client sends some request headers to the server, and the server responds with the requested content along with HTTP 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:values ​​used to pass technical information, such as the type of resource requested, how the browser caches content, and more.

You can check the plain-text information of the HTTP response headers using a simple cURL command, with the —head option. Here is an example:

By setting the right security headers in your web applications, you can increase your resistance to attacks.

curl --head https://www.securecoding.com/
Server: nginx
Date: Wed, 21 Jul 2021 16:05:03 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
...
X-Kinsta-Cache: HIT
Content-Encoding: gzip
...

HTTP Strict Transport Security (HSTS)

The HTTP Strict Transport Security (HSTS) is a response header that allows you to instruct the browser that interactions should only be held over a secure HTTPS connection and not over the HTTP protocol.

For example, if a web application allows connections via the URL http:// before redirecting the visitor to https://, this initial unencrypted interaction of the application can create an opportunity for different types of attacks, such as man-in-the-middle.

With HSTS, you can tell the web browser that it should never access an application via HTTP. Any attempt to load the web application via HTTP is automatically changed to HTTPS.

Here are the HSTS options:

• max-age= – make sure the browser accesses the app using HTTPS within the specified number of seconds.
• includeSubDomains — a parameter that ensures HSTS is applied even to subdomains of the current domain.
• preload — a parameter used when a web application has been received HSTS preload list.

Here is an example of how you can implement HSTS:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
//note that 31536000 seconds is equal to a year.

X-Frame-Options (XFO)

X-Frame-Options (also known as XFO) is a response header that allows or prohibits web browsers from rendering pages within the “frame”, “iframe”, “embed” or “object” HTML tag.

HTML iframes allow a child web application to be nested within a parent web application. While they provide useful features, an attacker can use them to embed a legitimate web application into a malicious web application. This makes the application vulnerable to click-jacking attacks; i.e., trick the user into clicking on a malicious web page element.

With XFO, you can tell the browser to apply restrictions that prevent your web application from being iframed. This can prevent an attacker from embedding your web application in a malicious website and tricking the user into performing malicious actions.

Here are the XFO options:

• DENY — block iframes completely.
• SAMEORIGIN — only iframes are allowed for apps on the same domain.

Here is an example:

X-Frame-Options: SAMEORIGIN

Content Security Policy (CSP)

The Content Security Policy (CSP) is a response header that allows you to control the type of resources a web browser can load for your web application. This is an effective way to whitelist your app’s content sources.

With CSP, you can protect your web application against malicious content execution — such as from XSS, click-jacking, or other types of injection attacks.

Here are some popular CSP options:

• default-src– acts as a backup source. For example, default-src ‘self’ loads all content from the current domain.
• script-src — specify allowed sources for scripts. For example, script-src myjsscript.com only loads scripts from the specified website.
• img-src — specify allowed sources for favorite images and icons. For example, img-src * allows to load images from any online source.

Here is an example:

Content-Security-Policy: default-src 'self'; script-src myjsscript.com; img-src *;

X-Content-Type-Options

X-Content-Type-Options is a response header that allows you to protect against content type vulnerabilities or MIME vulnerabilities.

MIME sniffing is a feature that most web browsers use to check (and fix) the content type of the resource being loaded. For example, the browser may be asked to display the image at /my-best-image.png, but the server did not set the correct content 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 this case, the web browser will ignore the headers Content-Type sent by the server and interprets the file in the specified format. This will ensure the image is displayed properly.

While MIME sniffing is a useful browser feature, it can lead to a serious security hole. For example, if your web app allows users to upload their own images, visitors could upload an image file containing malicious HTML code to your web app. In such a case, the browser will ignore the image content type and instead of displaying the image, the browser will execute that malicious HTML code.

With X-Content-Type-Options, you can instruct the browser to avoid sniffing when handling fetched resources. The browser will keep the value set in Content-Type.

It has only one option:

• nosniff — prevent MIME-type sniffing attempts.

Here is an example:

X-Content-Type-Options: nosniff

Clear-Site-Data

Clear-Site-Data is a tresponse header that allows you to instruct the browser to avoid storing sensitive web application information.

You can use it to clear all browsing data — such as cache, memory, and cookies — associated with your web application. For example, after a user logs out, you can use this header to ensure that all data stored on the client side is deleted.

Here are the Clear-Site-Data options:

• cache — delete all locally cached content.
• storage — deletes all content stored in the DOM.
• cookies — delete all cookies.
• *(repserentative character) —clears all types of browsing data.

Here is an example:

Clear-Site-Data: "*"

Conclusion

Most modern web browsers support some kind of HTTP header. You can leverage them to enhance the security of your web applications. By correctly configuring headers, you can strengthen your defenses and protect against common attacks.

In addition, you can also see how to find security holes using OWASP ZAP here.