Whether you have noticed or not, over the past couple of years, there has been a new security drive happening on the web – the rise of declarative security policies. i.e., declaring security policies via HTTP response headers. With respect to configuration, this is the simplest method of enhancing security of existing web applications. This post helps web developers understand about these security policies.
What is Declarative security model and why is it needed?
Over the years, security researchers have proposed several solutions to mitigate web attacks (e.g., XSS) in the form of server side or client side fixes. e.g., server side input sanitizers, regular expression based filters etc. These solutions have been providing good defense against attacks like XSS but they are not invincible. Even today, security experts are able to trivially bypass input sanitizers using clever obfuscation techniques. The problem is, these solutions attempt to fix the problems of the browsers. In principle, if browsers have security flaw, they have to be fixed instead of web applications trying to incorporate the fix. Also, for emerging attacks like Clickjacking, it is proven that code fixes in web applications will not resolve the issue and fix has to go into the browser.
All of a sudden if these security defenses are tightly incorporated into existing browsers, they break millions of web pages. There needs to be a balance between ensuring backward compatibility and enhancing security, which is a tricky situation. So, researchers had to come up with a mechanism/model wherein the desired security protection could be sent as a parameter at run time and browsers enforce the protection. Such a security model is known as declarative security model and it can be enforced using HTTP response headers.
Few declarative security headers:
X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, X-Download-Options, X-Content-Security-Policy etc., are some of well known declarative security headers which attempt to fix several security problems. The “X” prefix in these headers is commonly understood as eXperimental or eXtension (Note: X-prefix is deprecated). These are custom headers and not yet a part of HTTP spec (RFC2616), which means, one or more browser vendors have implemented how these headers should be understood by browsers as per their requirements. Here is a brief overview of how some of these headers help:
X-Frame-Options: This header was introduced by Microsoft to defend against Clickjacking attacks. When the value of this header is set to “DENY” in HTTP response of a web page, it prevents the page from being iframed. All major modern browsers support this header. More info can be found in IE blog.
X-XSS-Protection: This is again introduced by Microsoft to defend against Reflected-XSS attacks. When this header is set to 1, it triggers XSS filters of browsers and prevents script injections. More about this in IE blog.
X-Content-Security-Policy (CSP): This is introduced by Mozilla and is the latest in the list of secure HTTP headers. CSP aims to defend against a broad range of content injection vulnerabilities and to some extent content exfiltration. XSS has been a major problem for several years now and though there were several research proposals to defend against XSS, CSP won the race and is being standardized by W3C. Here is the CSP spec. Watch out this spec! The promises made by CSP are huge!
Who has to use them?
Everyone! But unfortunately, statistics show that these security headers have a very low adoption rate-the primary reason being lack of developer awareness. As per a recent report, only 8 of top 1000 Alexa sites use any declarative security header. Latest data on HTTP header usage is available for download from the database of ShodhanHQ.
So to conclude, web developers need to understand the importance of declarative HTTP headers and their importance for enhancing security. Browser security has been evolving at a rapid pace along with evolving web specifications and hence web developers need to upgrade themselves with these skills as well.