- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Thu, 27 Jan 2011 09:57:52 -0800
- To: Brandon Sterne <bsterne@mozilla.com>
- Cc: public-web-security@w3.org
> 2. Content restrictions > a. allow: catch-all for content-types not specified in policy > b. img-src: domains permitted to load images > c. media-src: domains permitted to load <video>, <audio> > d. object-src: domains permitted to load plugin content > e. frame-src: domains permitted to be loaded in <iframe>s > f. font-src: domains permitted to load fonts > g. xhr-src: domains permitted to send XHR to > h. style-src: domains permitted to load stylesheets I wonder about the extensibility of it: since the inception of CSP, we have already witnessed the arrival of new content classes (font-src); plus, there are some types of content loads that are not covered by these categories (say, favicon). The catch-all category is confusing, probably. I can see two options: 1) Make it less granular, and group content types by their security impact: have one class for passive multimedia, one for nested documents, and another for scriptable content? 2) Make it more granular but simply tie it to the relevant tag name. So, we could have allow[img] = ..., allow[embed] = ..., etc. This is more immediately extensible, and allows unrecognized rules to be skipped more confidently. > 4. Clickjacking protection > a. frame-ancestors: list of domains permitted to embed the resource > in an iframe I think there are cases where people would want to enforce the rest of their policy strictly, but only be notified on frame-ancestors violations (by DOM or on server-side). This makes me wonder if we should make the enforce / notify switch more granular; it would lessen the pain of deploying the policy, too: request soft reporting of frame-ancestors or img-src, but enforce script-src. /mz
Received on Thursday, 27 January 2011 17:58:45 UTC