> 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