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: email@example.com.
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.
Dig Deeper on Web application and API security best practices
Related Q&A from Michael Cobb
See which encryption method uses digital signatures, symmetric key exchanges, bulk encryption and much more in this Diffie-Hellman vs. RSA showdown. Continue Reading
Explore the differences between symmetric vs. asymmetric encryption algorithms, including common uses and examples of both, as well as their pros and... Continue Reading
WhatsApp vulnerabilities can enable hackers to bypass end-to-end encryption and spoof messages. Expert Michael Cobb explains how these attacks work ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.