Opened 11 years ago
Closed 11 years ago
#13507 closed bug (cantfix)
jQuery, CSP and Google Chrome 25
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | 1.9.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
I believe this is continuing on from bug #11249... but now effecting Google Chrome 25.
If CSP is enabled, you immediately get the error:
Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.
This happens with:
div.cloneNode( true ).style.backgroundClip = "";
Commenting out this line does fix it, but presumably effects the test for #8908.
Change History (8)
comment:1 Changed 11 years ago by
Owner: | set to craig@… |
---|---|
Status: | new → pending |
comment:2 Changed 11 years ago by
Status: | pending → new |
---|
In my case, I had a fairly simple header:
X-WebKit-CSP: default-src 'self'
I'd have thought that would allow style rules to be set via JavaScript... but it looks like it needs unsafe-inline:
X-WebKit-CSP: default-src 'self'; style-src 'self' 'unsafe-inline'
It is strange that this trips on the cloneNode(true) line though, rather than line above.
div.style.backgroundClip = "content-box"; div.cloneNode( true ).style.backgroundClip = ""; support.clearCloneStyle = div.style.backgroundClip === "content-box";
comment:3 Changed 11 years ago by
Is https://github.com/jquery/jquery/blob/dc9b009c1325e05344fa2216fac71fac3a0a0590/test/data/support/csp.php not testing this correctly? I do see the CSP violations, but also the test passes on BrowserStack Chrome 25.
comment:4 Changed 11 years ago by
Can check later... but I believe the simple check it uses will still pass:
jQuery(function() { parent.iframeCallback( jQuery.support ); });
As the CSP violation just stops the property from being set, but the code will continue to run anyway... as in, it runs fine (possibly getting that test result wrong), and throws the error in the console (and via the reporting url, if set).
comment:5 Changed 11 years ago by
Status: | new → pending |
---|
comment:6 Changed 11 years ago by
Status: | pending → new |
---|
This is still a problem, and can be isolated by setting the header:
X-WebKit-CSP: default-src 'self'
And then running the following:
div1 = document.createElement('div'); div1.style.background = 'red'; var div2 = div1.cloneNode(true);
This has also been reported to Chromium:
However a more immediate solution may be required for jQuery... of which commenting out the div.cloneNode line seems to work (although presumably it breaks the test).
comment:7 Changed 11 years ago by
It seems to me that this is definitely a bug in Chrome, because cloning an existing element should not trigger the CSP issue. And yes, we can't just comment out the line, it is there for a reason. This is good info though, and since you've reported the bug we can track it from here.
The remaining question is whether our unit test is working properly. If the test worked it seems like we'd need to remove it. :)
comment:8 Changed 11 years ago by
Resolution: | → cantfix |
---|---|
Status: | new → closed |
That particular support test isn't affected by the blocked access anyway so other than a harmless (erroneous) CSP warning we're good.
Commenting out that line probably gets you through the initial feature detection but it's likely to hang up on other code later, for example effects.
It seems like we need to require that jQuery be run with
style-src self
or a URL appropriate to where the jquery.js file originates. Is there a reason you're unable to specify that?