Strict Content Security Policy (CSP) blocks inline script

We’re in the process on GOV.UK Pay of implementing CSP in our apps and the inline script here gets blocked.

We can whitelist it with the hash of it’s contents which works until it gets changed, which I am sure doesn’t happen too often. So maybe this is fine, it secure at least as it means, we‘re not trusting GOV.UK Frontend without explicitly checking here. But it would also mean if no one noticed, this could get blocked and break some functionality.

But I wondered if we could wrap it a block so if we wanted to we could override it we could.

Option 1

{% block inlineJsCheck %}
    <script>document.body.className = ((document.body.className) ? document.body.className + ' js-enabled' : 'js-enabled');</script>
{% endblock %}

Option 2

    <script nonce="{{ inlineJsCspNonce }}">document.body.className = ((document.body.className) ? document.body.className + ' js-enabled' : 'js-enabled');</script>

[NickColley]

@jonheslop I think GOV.UK Frontend should aim to support the most proper way of doing this, if that’s adding a hash we should consider adding something to our documentation. What do you think?

[Nooshu]

I’ve also heard that SRI is now considered and anti-pattern and may even impact perf, but I’ve yet to see any concrete evidence of that.

Updating this issue as we now have more information on this. Subresource Integrity (SRI) has an impact on HTTP/2 coalescing, which in turn can cause web performance issues. Personal blog post about it here and a RFC related to changes we made on GOV.UK