Cross-site scripting (XSS) is a common web application flaw that can lead to a wide variety of attacks. The problem, and ways to eliminate it, have been known for years, but new instances of XSS crop up regularly in web applications—live sites as well as packages like content management systems. Mozilla has taken the lead on a new security policy, Content Security Policy (CSP), which provides a way for sites to avoid XSS. It does that by fundamentally changing the way JavaScript content is treated by the browser, but does so in a way that allows sites to opt-in to the new policy.

XSS works by injecting JavaScript content into the data returned by a web server. Normally that happens because some kind of user input was not properly filtered before it was echoed back on a web page. If that user input—in the form of a comment on an article, for example—contains unfiltered JavaScript, the users browser will happily execute it as if it originated with the site. At that point, an attacker-controlled code is running with the privileges of the browser user and the origin site.

As described by Mozilla's security program manager Brandon Sterne, on the Mozilla Security Blog, CSP changes that model. Instead of treating all content received in a response as having the same privilege level, CSP allows the site owner to explicitly list what kinds of JavaScript to trust. In order to do that, however, CSP strictly limits where JavaScript can originate, and where it can appear in HTML.

Basically, CSP allows a site operator to list hosts from which JavaScript content will be accepted. If that option is used (via an HTTP X-Content-Security-Policy header or HTML <META> tag), all JavaScript must be loaded from external files from hosts on the list—all other mechanisms for executing JavaScript are disabled for that page. Sterne describes it this way:

This will be an enormous change for sites that want to use CSP, but it is backward-compatible with older browsers (or those that do not support CSP), and there are ways to incrementally approach the implementation. Sterne notes that all sites should be able to make the switch, and Mozilla intends to provide a migration guide to help sites convert to CSP. But, it remains to be seen whether sites will actually use it. Mozilla security lead, Daniel Veditz, commented about that in the bug entry that tracks CSP implementation:

Another interesting feature of CSP is its ability to notify a site when there is an attempt to violate the policy. This will even benefit users of browsers that don't support CSP, as XSS holes can be recognized and fixed more quickly. Sterne is optimistic about the effect of CSP:

The open question is whether site operators are concerned enough about XSS to change the way they handle JavaScript. Over time, automated tools may help with that process, which could lower the bar somewhat, but it is still a daunting task. One would guess that the other browsers will take a "wait and see" attitude before deciding whether to implement it. Though the implementation is progressing, there is no word from Mozilla on when it might release a browser with CSP either.

Perhaps CSP is too heavy-handed of a solution to the XSS problem, but it is good to see Mozilla taking a lead in trying to find something that will alleviate the problem. There are other, similar efforts in the works at Mozilla including the Origin header to mitigate cross-site request forgery and clickjacking.

While these web application vulnerabilities are largely understood and techniques to avoid them are known, they keep cropping up. Finding ways to make users' browsers more resistant to these kinds of attacks can only help improve web security.