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:
- 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.
- 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.
- 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:
- 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.
- 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
Conclusion
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.