Bug 70463 - CSP blocks src-less plugins when enabled
Summary: CSP blocks src-less plugins when enabled
Status: RESOLVED DUPLICATE of bug 71426
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://davidben.net/csp-test.html
Depends on:
Blocks: 53572
  Show dependency treegraph
Reported: 2011-10-19 17:46 PDT by David Benjamin
Modified: 2012-01-18 23:18 PST (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description David Benjamin 2011-10-19 17:46:18 PDT
Having a Content-Security-Policy enabled blocks <embed> tags without a src attribute. I've put together a quick test case at


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.

Comment 1 Adam Barth 2011-10-19 22:23:22 PDT
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.
Comment 2 David Benjamin 2012-01-18 23:18:00 PST
Looks like this got tracked elsewhere and fixed.

*** This bug has been marked as a duplicate of bug 71426 ***