Tying myself in knots over CSP

Bloke · Today 18:32:19

I have a site that has a tonne of CSP rules in .htaccess. Client needs to implement gtag.js for google tag management click-for-sales tracking, so every page needs some inline JS code, top and tail. I added it. Tweaked the CSP rules in .htaccess to allow a load of google domains, and it loaded stuff, but the script itself is being blocked. This is what they said:

I’ve looked into the site and confirmed that the header and footer tags are implemented correctly. However, the current Content Security Policy (CSP) is blocking the Google tag from firing.

Could you please ask your web developer to update the policy? They may need to adjust the settings to allow Google’s domains. For technical guidance, they can refer to this documentation:

https://developers.google.com/publisher-tag/guides/content-security-policy

Please let me know once this has been updated so we can verify the conversion tracking.

I’d already added all the domains, and the console was quiet, so I’m not sure what they were talking about. So I delved into the above link. It harps on about there being two methods to satisfy Google, but they’ve decided to only permit one of them: nonce values (btw, the internal links to strict-csp information in the above doc don’t resolve but this one does).

So I installed smd_token and used this trick to add nonce values to all script and style tags:

<script<txp:variable name="nonce-attr" />>

everywherre I could. Then added a header tag to my page template:

<txp:header name="Content-Security-Policy-Report-Only" value='script-src ''nonce-<txp:variable name="nonce" />''' replace="add" />

I think that works. If I look at the root request in the Console’s Network pane, it shows two CSP headers being sent: the above one from the page template, followed by the CSP block from .htaccess. So, all good.

Sort of.

That now has a knock-on effect. Some other page scripts (for example those generated by aweber.com) load third party scripts that themselves contain unsafe operations that violate the parent <script> tag’s nonce. For example, they use skulduggery such as document.createElement('script') and s.innerHTML = formString; (where formString is some manually built-up <script> or <style> element).

I have no control over the content of these links as they’re auto-generated on the fly. The Console reports this, over and over (but each error has a different hash value suggested):

Content-Security-Policy: (Report-Only policy) The page’s settings would block an event handler (script-src-attr) from being executed because it violates the following directive: “script-src 'nonce-0f89f54......'”. Consider using a hash ('sha256-wQXsc3opGVK3......') together with 'unsafe-hashes'.
Source: this.style.transform='scale(1.2) rotate(…

But I can’t fathom how to actually implement that. Do I need to add the hashes to the .htaccess file somehow? If so, how do I make them unique? Or do I need another CSP rule for script-src-attr in my Page template that adds a second smd_token value as an SHA256 hash? (Can the plugin even generate those? I’m not sure it can.)

And even if I can, how do I then tag the relevant attributes in the 3rd party code to load them if the hashes match?

On a broader note, do I need both nonce-based and .htaccess-based CSP rules? Or can I remove the script-src rules from .htaccess if I’ve implemented nonces throughout for script loading?

I’m getting in a real muddle here, and at every turn there’s yet another stumbling block that throws more spanners in more gears. It can’t be this hard to implement without splattering unsafe-whatever rules throughout… can it?

jakob · Today 22:03:03

Sorry, no solution to hand. All I can say is I feel your pain.

Textpattern CMS

Textpattern CMS support forum

#1 Today 18:32:19

Tying myself in knots over CSP

#2 Today 22:03:03

Re: Tying myself in knots over CSP

Board footer