We currently have an inline script tag in the page template that adds the 'js-enabled' class
<script>
document.body.className = ((document.body.className) ? document.body.className + ' js-enabled' : 'js-enabled');
</script>
This is for usability reasons: we don't want to have to wait for the GOV.UK Frontend JS file to load before the correct classes and styling is applied - this approach avoids the flash of content for instance hiding the toggleable content of details and accordion components.
If you have Content Security Policy (CSP) enabled for your application, you might see something like:
Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-+6WnXIl4mbFTCARd8N3COQmT3bJJmo32N8q8ZSQAIcU='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.
and the inline script is blocked.
See alphagov/govuk-frontend#1811 and alphagov/govuk-frontend#1657
Generate a hash of the script, include it in your CSP:
Content-Security-Policy: default-src 'self'; script-src 'sha256-+6WnXIl4mbFTCARd8N3COQmT3bJJmo32N8q8ZSQAIcU='
We don't expect the script tag to change much, if almost ever, so the hash will stay fairly static.
A change to the hash would be treatead as a breaking change, in case teams copy it manually instead of fetching it from the npm package.
More convenient than the hash as you won't have to recalculate the hash every time the script tag changes (but we don't expect the script tag to change much - see above).
There are some reported ways to bypass nonces.
Adding a nonce to the page template markup would be a breaking change.
Speak to frontend community- Speak to GOV.UK regarding RFC 98
- Check approach with cyber security