Retour 
Enterprises are rapidly adopting cloud applications across various functions. It is important to consider the enterprise readiness of these applications as they are being used to store sensitive data. An important aspect of this is the susceptibility of these applications to attacks that could compromise the data. In this blog post we will look at the advances being made in the realm of http protocol that would address these threats and the adoption of these techniques across the universe of cloud applications.
In the past decade, myriad techniques have been developed to compromise web applications, ranging from cross site scripting (XSS) and SQL injection to phishing and clickjacking. As web applications have become more sophisticated, so have modern web browsers which in turn has spurned newer attacks and, consequently, their defenses. HTTP security headers are a set of new HTTP response headers proposed to help enhance a website’s security. These headers turn on the inbuilt defense mechanisms in a compatible browser and protect from XSS, clickjacking, MIME sniffing vulnerabilities and Man-In-The-Middle attacks etc.
What are HTTP Security Headers?
The following are 5 security headers and a brief introduction to each of them.
- HTTP Strict-Transport-Security (HSTS):
HSTS headers protect against Man-In-The-Middle attacks. If a website uses an HSTS header, the header enforces that all content from the domain is downloaded over HTTPS and also refuses to connect in case of certificate errors and warnings. A typical HSTS response header looks like:
Strict-Transport-Security: max-age=31536000; includeSubDomains
For example: If the website http://foobar.com includes an HSTS header in the response, then next time on connecting to foobar.com, the browser will force a connection to https://foobar.com.
- Content-Security-Policy (CSP):
The Web’s security model is strongly dependent on the same origin policy. Basically, the content from https://foobar.com should only have access to data from https://foobar.com and should not have access to https://evil.com.
In a cross-site scripting (XSS) attack, the browser is tricked into delivering malicious content by bypassing the same origin policy. The root cause in case of XSS is the browser’s inability to distinguish between the scripts that are part of the application and scripts which have been injected by a third party.
CSP provides a mechanism to instruct browsers on what to trust. By using CSP, a allow list policy is enforced on the content being delivered, i.e, content can only be delivered by certain specified domains.
For example: by specifying following in the HTTP response header:
Content-Security-Policy: script-src ‘self’ https://apis.google.com
the browser is instructed to load scripts only from the current domain and apis.google.com.
Content delivery for the following types can be allow listed using CSP: javascripts, css, html frames, fonts, images, embeddable objects – java applet, activex ,audio, video files.
CSP also provides the ability to automatically turn on sandbox mode for all iframes on a website. CSP protects against XSS, data injection attacks, protection against data theft, distribution of malware etc.
- X-Frame-Options:
X-Frame-Options is a simple solution for preventing Clickjacking attacks. Inclusion of this header in an HTTP response enforces the browser to evaluate a request of framing a page. ‘SAMEORIGIN‘ value will allow the page to be displayed in a frame on the same origin as the page, while ‘ALLOW FROM https://foobar.com‘ allows framing of the page only on https://foobar.com.
For example: Specifying the following:
X-Frame-Options:Deny
prevents the page to be displayed in a frame.
- X-Content-Type-Options:
Most