Cookiebot custom script ignoring nonce and being blocked by CSP
Hello,
In my cookiebot dialog configuration, I have a custom script.
When it gets injected in the page, for some reason, it doesn't seem to inherit the `nonce` attribute from the Cookiebot script tag (the one that loads `https://consent.cookiebot.com/uc.js`). Since I'm moving from `unsafe-inline` to a `nonce-` based CSP, the inline script is being blocked.
Do you know how can I solve this without having to go back to `unsafe-inline`?
Thank you.
-
Hi @Maria, the script isn't being blocked by Cookiebot, it's being blocked by the browser, due to the missing CSP `nonce` attribute.
When `uc.js` injects the custom inline script tag, it should add the `nonce` attribute to indicate to the browser that the inline script can be trusted (a behaviour similar to other script-injecting tools, like Google Tag Manager).
For more information: https://content-security-policy.com/nonce/
0 -
I'm having the same issue.
It looks like uc.js clones the other <script> tags on the page, in dequeueNonAsyncScripts().
However, it seems that the nonce="" attribute isn't being copied over to the clone (or something like that). Interestingly, this problem only seems to happen with inline scripts (i.e., <script> doSomething(); </script>), and not with .js files (i.e., <script src="somefile.js"></script>).
As a result, the browser refuses to execute the cloned script, because it doesn't have a nonce, so it violates the Content-Security-Policy.
2 -
Travis Miller
it seems that the nonce="" attribute isn't being copied over to the clone
It's because the nonce attribute is hidden from the <script> element attributes list, for security.
this problem only seems to happen with inline scripts (i.e., <script> doSomething(); </script>), and not with .js files (i.e., <script src="somefile.js"></script>).
That's to be expected if your CSP allows the src of the script (eg. "script-src 'self'" for your example). Inline scripts are usually blocked by CSP, since it's a common vector of attack.
0 -
I'm having a similar issue with GTM. I also noticed what Travis has noticed, I think the script gets injected with incorrect nonce values, guessing this is because if I land on a page for the first time, cookiebot will take a snapshot of the scripts it blocks and their nonce values, and seeing as these values need to be unique per request, when i accetp cookies and refresh the page, a new nonce attribute is generated but the scripts are injected into the html with the original nonce values.
If this is the case (would you be able to confirm?) it would be good if we could provide the uc.js script a nonce attribute, and that could get used on the injected scripts
0 -
Would strict-dynamic in the script-src list in the CSP-header do the trick? I think that would propagate the trust provided to scripts by the nonce value to scripts injected by the script itself.
0 -
this problem only seems to happen with inline scripts (i.e., <script> doSomething(); </script>), and not with .js files (i.e., <script src="somefile.js"></script>).
That's to be expected if your CSP allows the src of the script (eg. "script-src 'self'" for your example). Inline scripts are usually blocked by CSP, since it's a common vector of attack site .
0 -
I am also having this issue, I am adding the nonce when importing the cookiebot script but it doesnt get copied over to the scripts cookitbot injects, can't really go back to unsafe inline, it looks like the issue is happening in dequeueNonAsyncScripts, Rafael Soares did you find a workaround?
0 -
James Heathcote not really. Until they fix this, we're stuck with either using `unsafe-inline` or declaring the JS functions directly in our site's source code (I haven't tried this myself, but as long as they're exposed globally, it should work).
0 -
I actually managed to sort of get this working, had to use strict-dynamic in the CSP and rewrite every import on the rest of my site to use a nonce string, only way I've found to get cookiebot working without unsafe inline
0 -
Hmmm, I'll need to test again, but I think I tried it with inline custom scripts and it didn't work. The documentation seems to suggest that it's meant for injecting additional <script src=""> tags.
0
Please sign in to leave a comment.
Comments
10 comments