- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Tue, 25 Jan 2011 10:57:41 -0800
- To: Adam Barth <w3c@adambarth.com>
- CC: Lucas Adamski <lucas@mozilla.com>, public-web-security@w3.org
On 1/24/11 3:50 PM, Adam Barth wrote: > To pick on one example, adding "inline" as script-src is disaster for > security, yet its temping enough that a number of folks who've I've > seen try to use CSP decide to add it. IMHO, CSP would be better at > mitigating XSS without the "inline" option for "script-src". technical nit: inline is not a script-src and hasn't been in any working code we've shipped. It goes in a completely different part of the policy, moved from early versions of the proposal to highlight the distinction that is not "just another source". Clearly a policy with "options inline-script" disables XSS protection. It will be documented as such and I expect site scanning tools to issue warnings if they are updated to know about Content-Security-Policy. Without that feature, however, developers converting existing sites have to choose between using CSP or not, black and white; with that option there is an intermediate step where they can gain the benefits of CSPs other features, enabling inline-scripts--disabling XSS protection--for specific pages that are not yet converted and removing it as they are. The option does undercut a major feature of CSP. If we want to get all hair-shirt on site developers we can cut it. We could also rename it for more clarity of its impact on the policy. "options allow-xss" perhaps? Or better, if wordier, "options disable-xss-protection"? Certainly those are less clear on what it does from an authoring POV, but maybe that will further discourage overuse. -Dan Veditz
Received on Tuesday, 25 January 2011 18:58:23 UTC