Modernizr: Content Security Policy restrictions error

Created on 12 Mar 2014  Â·  14Comments  Â·  Source: Modernizr/Modernizr

Demo

When CSP is on Modernizr can accidently crash entire app (when Modernizr comes as part of app file).

Most helpful comment

Pretty disappointing this still appears to be a problem. I did also look at hashes but if as @quinncomendant says the styles aren't static then a hash is out of the question.

strict-dynamic is worth looking at if you _exclusively_ use nonces since I think it might help here by allowing the trusted script Modernizr to inject non-parser content and not have them be considered a violation. For what I'm doing though, I still want to be using host-based whitelisting and Modernizr is the only script that breaks with this.

All 14 comments

+1 I too am looking for a solution to using Modernizr with CSP.

If you think CSP with style-src isn't important to prevent XSS, think again.

I haven't had time to finish a proper fix for this - in the mean time, you can add the sha of the modernizr file to your csp declaration to work around it

Using the sha hash of the Modernizr file won't do anything. CSP is blocking injected inline styles, not JS.
screen shot 2015-07-14 at 13 26 15

So the random unique value should work for inline styles with the nonce attribute. You'll need to generate this on your server and we'll need to create an api that will let you write the value to.

%script{:nonce => nonceValue}
   Modernizr.nonce = nonceValue

With that we could then add the styles with the correct nonce value, hopefully that allows dynamic injection.

I'll create a demo and try this out.

I'm not familiar with Modernizr's use of inline-styles, but if it is injecting CSS inside <style> tags on the page then use of a nonce is possible. The way to use this would be for the server-generated HTML to include the nonce in a data attribute of the HTML's <body> tag (matching the nonce sent in the Content-Security-Policy header):

<body data-modernizr-nonce="abc123">

Then Modernizer can capture and use this value for the nonces in its <style> tags, e.g.,:

<style nonce="abc123">…</style>

If Modernizr is injecting style in a style attribute (e.g., <… style="color: blue;"> then use of a nonce is not possible.

+1 for proper CSP support.

Its worth noting that using a nonce stops you from being able to cache the page. Using a hash is a better workaround.

Good point on nonce usage being non-cacheable.

I can't think how using a hash would be possible. The server would need to know the hash of the styles that will be generated once the HTML is received. How would Modernizer send a message backwards in time telling the server what styles it will generate? :-\

Pretty disappointing this still appears to be a problem. I did also look at hashes but if as @quinncomendant says the styles aren't static then a hash is out of the question.

strict-dynamic is worth looking at if you _exclusively_ use nonces since I think it might help here by allowing the trusted script Modernizr to inject non-parser content and not have them be considered a violation. For what I'm doing though, I still want to be using host-based whitelisting and Modernizr is the only script that breaks with this.

@lol768 prs welcome

@patrickhlauke What happened to the existing PR for this?

strict-dynamic is the Future of CSP
I guess it should be the appropiate way to deal with this Topic here.

https://w3c.github.io/webappsec-csp/#strict-dynamic-usage

https://speakerdeck.com/mikispag/making-csp-great-again-michele-spagnuolo-and-lukas-weichselbaum?slide=22

@lol768 you probably ment @patrickkettner in your question about existing PRs :-)

@fwebdev cant help you with knowledge about the state of CSP pull requests (or discussions around it) but would you be willing to push this issue forward?

@lol768 you probably ment @patrickkettner in your question about existing PRs :-)

I blame the autocomplete :P

Was this page helpful?
0 / 5 - 0 ratings