HTTP Security Headers: Best Way to Harden Web Applications

An HTTP header allows the client and the server to exchange information secretly with complete safety. By enabling specific headers in web applications and web servers one can protect the web application from XSS and clickjacking attacks. The headers are case insensitive. Hence, the headers field is separated with the help of colon, key-value pairs in clear string pair format.

Contribution of HTTP Headers for Security of a Web Application

The security of a web application includes exploiting the possible vulnerabilities before they damage the functioning of a web application. The headers also fix these issues in the application code. The headers restrict the improper activities allowed by the browser and server while the application is in function. This provides a layer of protection to the application. 

The HTTP headers keep changing as per the browser vendor support. Headers keep on changing because the new proposals of headers with beneficial working are immediately accepted within a month. It becomes a tedious task to manage all such headers. One should not immediately implement any header introduced. After the complete investigation and check one should use a header and its services. 

Crucial HTTP Security Headers

Let us have a look at some of the important HTTP Security headers with the best-known HTTP response:

  1. Strict-Transport-Security

When HTTP Strict-Transport-Security (HSTS) is enabled on a server it enforces the use of encrypted HTTPS connections. It avoids plain-text HTTP communication to maintain security standards. A typical HSTS header appears like this:

Strict-Transport-Security: max-age=63072000: includeSubDomains; preload

This helps the visiting web browser inclusive of sub-domain that the current site is HTTPS only. It should only be browsed over HTTPS for the span of the next 2 years with the max-age value in seconds. The preload directive helps one to indicate that the site is present on HTTPS-only sites on a global list. 

Preloading helps to speed up the loading of the page to avoid man-in-the-middle (MITM) attacks when someone visits the site for the first time. If a site accepts HTTP communication and later encrypts in HTTPS then the conversion period can be used for MITM attacks. Therefore, the Strict-Transport-Security header informs the browsing site in advance to immediately convert the HTTP communication into an HTTPS request. 

  1. Content-Security-Policy

The Content Security Policy (CSP) header is one of the recommended headers to keep your site safe from Cross-Site Scripting Attacks. The header helps allow one to specify the content to be browsed. It also has various other setting options to enhance security. A basic CSP header allows basic assents from the local original like:

Content-Security-Policy: default-src ‘self’

The header is inclusive of various other directives like script-src, style-src, and image-src. These directives help one specify the permitted sources for scripts, CSS style sheets, and images. For example, specifying script-src ‘self’ allows only scripts from the local origin. Plugin sources can also be restricted by using plugin-types or object-src.

The header is also helpful to identify XSS and data injection attacks. These attacks are used to deface a website, steal its data, and distribute malware all over. The header is designed to be fully backward compatible. 

  1. X-Frame-Options

The header X-Frame-Options was first introduced in Microsoft Internet Explorer. The header protects a website from XSS attacks inclusive of HTML iFrames. To avoid the current page being loaded into any iframes one can use:

X-Frame-Options: deny

sameorigin is another supported value with the same origin to allow loading into iframes. allow-from indicates specific URLs. Suitable CSP headers can replace X-Frame-Options headers. The response header can also be used to choose if a browser can render a page in a <frame>, <iframe>, <embed>, or <object>. Websites can use this to ensure that they are safe from click-jacking attacks. This also helps them to notify that their content is not embedded into other websites. 

Deprecated Security Headers

Some headers were introduced to deal with temporary security issues. Few of these were later disapproved due to few years of browser support. Mentioned below are the headers that were introduced to deal with specific vulnerabilities:

  1. X-XSS-Protection

The header was introduced to protect a website from JavaScript Injection Attacks through cross-site scripting. Its usual syntax was: 

X-XSS-Protection: 1; mode=block

The header was introduced for browsers with XSS filters to have control of the filtering functionality. With the help of the header, it was easy to bypass or abuse the non-relative content. The modern browsers now do not use XSS filters therefore the header was soon deprecated. 

  1. Public-Key-Pins

To prevent certificate spoofing HTTP Public Key Pinning (HPKP) was introduced in Google Chrome and Firefox. The header had a complicated mechanism web client was presented by the server with cryptographic hashes. Valid certificate public keys were used for future communication. The header was found too complicated for practical use. If this complication led to improper configuration the header completely disabled the website access until the time specified in the max-age parameter. 

Other Helpful Security Headers

Though the headers mentioned below might not be as crucial as CSP or HSTS but are helpful too to maintain the security and protection of your website. Let us have a look at them:

  • Expect-CT
  • X-Content-Type-Options
  • Fetch Metadata Headers
  • Referrer-Policy
  • Cache-Control
  • Clear-Site-Data
  • Feature-Policy


HTTP security headers help one to improve the security measures taken to protect a web application. The headers also help to protect the application without bringing enormous changes to it. Therefore, it is always advised to use current headers.

Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post

How to Prevent LDAP Injection Attack?

Next Post

Top 10 Vulnerabilities in the List of OWASP

Related Posts