CSP and Rocker Loader break my Website


I’m getting console errors with my content security policy (CSP) regarding CloudFlare’s Rocker Loader script (https://ajax.cloudflare.com/cdn-cgi/scripts/cb7744ae/cloudflare-static/rocket-loader.min.js) that effectively breaks my Website unless I add unsafe-inline to the script-src section of my CSP header. (I really don’t want to have to do that. After all, security is the main reason I use CloudFlare.)

The reason for this is that I already have https://ajax.cloudflare.com in my CSP header, yet I still get the error:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' https://www.google-analytics.com https://apis.google.com https://www.googletagmanager.com https://ajax.cloudflare.com https://js.pusher.com https://js.pusher.co

Additionally (if I’m correctly understanding how the script works) I don’t believe I’m able to add an SRI hash for the script anywhere, as I understand it has to be placed in the script src tag that calls the script, and I that’s something that’s added en-route by CloudFlare.

Thank you!


I had the same problem. I ended up disabling Rocket Loader so I don’t have to use unsafe-inline.

I wish there was an option within Rocket Loader to not mess with inline scripts.

1 Like

I’ve found the solution to our problem. I can insert the hash directly into the CSP header in the script-src section. The hash for this particular script is sha256-OUYk9hAp4V/FupIK6DvE3g4hpltYnldjWxtJgXDnBPY= This allows the Rocket Loader script to load without resorting to unsafe-inline

I’ll keep plugging away and see if anything else breaks as I harden my server. Hopefully this solution helps other people, too!

1 Like

You can also use 'strict-dynamic` more information can be found here.

Aside from using your web browsers dev tools to suggest hashes, here are some tools to evaluate those your headers. https://observatory.mozilla.org/ and https://securityheaders.com/

1 Like

Thank you for the tip and resources!

1 Like

BTW, when testing/modifying your headers, it’s a good idea to put Cloudflare in to Development Mode, run the Web Browser InPrivate and in DevTools, check Disable cache (while DevTools is open)

1 Like

I often use hashes, but…it might be my imagination…but Rocket Loader hashes change, breaking my pages due to CSP blockage.

1 Like

Updated scripts can break hashes and why it’s really handy to use all-in-one reporting tools such as Report URL https://report-uri.com/home/tools that reports violations for CPS, Expect-CT, XSS, NEL, DMARC etc. Free for up to 10,000 reports/mo


Oh…but I do use Report-URI and love it. But I don’t check it every day and don’t like having CSP break my site when my back is turned. Sad to say I’ve had to resort to unsafe-inline for sites where the inline scripts frequently changed based on dynamic page content.

1 Like

Agreed. It’s pretty hard to avoid in some cases and anything is better than nothing.
Sometimes we create unique headers for specific directories. One that comes to mind is /wp-admin and sites using WordFence. We lock down the directory anyways.

1 Like

Well son of a biscuit… the hash doesn’t work now. And I even create a fresh hash and place it in the header and still nothing. What gives? It was just working, and now I can add hashes until I’m blue in the face, and nothing.

Why is including the URL for allowed scripts not working only for CloudFlare? What am I missing? All other external scripts are loading fine.

1 Like

hard to say. Are you caching anything, anywhere including your web browser? You’ll see that a lot with Google fonts. Let one in the door then get 30+ violations for all the others… lol


Hashes are for inline scripts. External scripts are easy. It’s either ‘self’, or a domain. And that doesn’t change. Inline scripts can change if the code decides to do something different.

closed #14

This topic was automatically closed after 30 days. New replies are no longer allowed.