Bug 70463
Summary: | CSP blocks src-less plugins when enabled | ||
---|---|---|---|
Product: | WebKit | Reporter: | David Benjamin <davidben> |
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | abarth, sam |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | http://davidben.net/csp-test.html | ||
Bug Depends on: | |||
Bug Blocks: | 53572 |
David Benjamin
Having a Content-Security-Policy enabled blocks <embed> tags without a src attribute. I've put together a quick test case at
http://davidben.net/csp-test.html
It sends "default-src 'self'" on both X-WebKit-CSP and X-Content-Security-Policy. The contents are a Flash applet with no src and an image from another site just to make sure CSP is working at all. In the latest Chromium nightly, both are blocked and I get
Refused to load object from '' because of Content-Security-Policy.
in the console. In Firefox only the image is blocked, and I get an (uninteresting) Flash applet. But Flash does still load. I think it makes more sense for CSP not to trigger here since nothing from another origin is actually being loaded (and this block can be circumvented by putting in a dummy src from the same origin anyway). This is particularly relevant if I want to turn on CSP for a Chrome extension that embeds an NPAPI plugin into the background page; they're often src-less, including in the example.
http://code.google.com/chrome/extensions/npapi.html
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Adam Barth
There was a thread about this on the public-web-security mailing list. There wasn't a clear resolution about what to do with URL-less plugins. My sense is that they should be treated as having the URL of the enclosing page, which would let you block them with 'none' for example.
David Benjamin
Looks like this got tracked elsewhere and fixed.
*** This bug has been marked as a duplicate of bug 71426 ***