- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 2 May 2012 22:05:48 -0700
- To: public-webappsec@w3.org
At the face-to-face today, we talked through the proposed directives on the wiki page: http://www.w3.org/Security/wiki/Content_Security_Policy The sense I got from the room was that there was significant interest in the following set of directives, so I moved them to the "Proposals for Version 1.1" section of the wiki: * sandbox. This directive was in CSP 1.0, but it's looking like we're going to move it to CSP 1.1 so that we can move CSP 1.0 along the W3C process faster. * The ability to convey a CSP policy in a <meta> tag. This used to be in the CSP 1.0 spec, but was punted because it needed some further polishing. We talked it over at the face-to-face and generated some good ideas for how to improve on the previous design. I'll post more details once I write them up in a coherent way. * A DOM API for reading the policy, likely something akin to <https://mikewest.org/2012/05/content-security-policy-feature-detection>. * script-nonce. This directive lets sites further lock down scripts by requiring that <script> elements need to both satisfy the script-src directive AND have an attribute containing a nonce declared by the script-nonce directive. * frame-ancestor and/or frame-options. We should coordinate with the IETF websec working group on Frame-Options to see whether it makes more sense for that to be a CSP directive rather than yet-another-security-policy-in-an-HTTP-header. * form-action. This directive lets site restrict which URLs can be used as the actions of forms. In Postcards from the post-XSS world <http://lcamtuf.coredump.cx/postxss/>, lcamtuf previews for us the kinds of XSS attacks sites will need to deal with after deploying CSP. The form-action directive helps with some of these and fits nicely in with the CSP 1.0 directives, so it seems like a win. * plugin-types. This directive lets sites provide a whitelist of plugin MIME types they allow. For example, a site could whitelist Flash, thereby excluding Google Gears. Some folks wanted to be able to specify which MIME types were acceptable from which origins, but we couldn't come up with an elegant syntax. * More granular source like (e.g., by directory). Rather than whitelisting an entire origin, sites might wish to whitelist only certain directories within those origins. For example, script-src https://example.com/js; style-src https://example.com/css There's some question about whether how we want these sorts of policies to be interpreted by a CSP 1.0 compliant user agent. We might need to tweak the CSP parser slightly to make this work well. Please note that this is just a very rough sketch of which directives we're going to work on for CSP 1.1. Please feel encouraged to send ideas for new directives to the list and to add them to the wiki. If you hate these directives or love other directives, please also feel encouraged to make your feelings known. :) Thanks! Adam
Received on Thursday, 3 May 2012 05:16:56 UTC