The W3C not long ago published a draft specification covering Web content security policy and how to architect applications against content-injection attacks like cross-site scripting. Reading a W3C spec is like reading a foreign language. Are there any new recommendations we should try to put in front of our Web developers?
Ask a question
SearchSecurity.com expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit your question via email: firstname.lastname@example.org.
In the W3C's defense, it is a real challenge to write a specification that is clear and understandable, yet precise enough that those tasked with implementing it won’t misinterpret it. I agree that plain English is not used widely enough when it comes to Web standards. This could be why there are browsers that display standardized HTML and CSS code differently. However, The W3C's primary recommendation to implement a content security policy is straightforward.
First, set the goals for the content security policy. Modern websites are highly complex and, given differences in cross-browser implementation, browser bugs and character escaping rules in various HTML contexts, it is easy for a developer to unwittingly introduce a security hole. This is why even the biggest sites on the Web have been unable to prevent cross-site scripting attacks. The content security policy specification aims to prevent content injection attacks by enabling Web administrators to specify the permitted sources of content in their Web applications and to restrict the capabilities of that content. A browser operating under a content security policy only loads and executes types of content received from the whitelisted domains that is specified in a site’s content security policy. In addition to restricting the domains from loading content, the server can specify which protocols are allowed to be used. For example, a server can specify that all content be loaded using HTTPS.
The policy is implemented via a simple code string, which contains the directives describing a content security policy. Enabling a content security policy is as easy as configuring a Web server to return the X-Content-Security-Policy HTTP header. For example, if an organization wants to restrict video content to come from only trusted providers and scripts to come from Google, its header would read:
X-Content-Security-Policy: allow self; media-src trusted video1.com trusted video2.com; script-src ajax.googleapis.com
Try the Mozilla Developer Network for more intuitive examples. Currently, the content security policy specification is only a public working draft published by the W3C's Web Application Security Working Group, but it is intended to become a W3C Recommendation, or essentially an industry standard. There are experimental implementations in Firefox and Chrome that use the header names X-Content-Security-Policy and X-WebKit-CSP respectively, while IE10 also contains a partial implementation that uses the header name X-Content-Security-Policy.
A content security policy is not intended to be a fool-proof silver bullet, but it does provide an effective layer of security that enhances a site's existing defenses. Given the protection it provides (it also mitigates clickjacking and packet-sniffing attacks), it is worthwhile for developers to take the necessary time to understand and implement one. A content security policy is backwards compatible, so a browser that does not support it disregards the content security policy header. Considering that browsers are increasingly using automatic updates though, a higher percentage of users are using the updated versions of browsers, which should be protected from attacks.
This was first published in April 2012