Refused to load the script because it violates CSP: nonce mismatch fix

Not specified by the original author.

Refused to load the script because it violates CSP: nonce mismatch fix

TL;DR

The script tag's nonce does not match the nonce in the CSP header, usually because a cached page serves a stale nonce or the value is generated per request but rendered once. Generate one nonce per response, inject the same value into the header and the tag, and exclude the page from caching.

Refused to load the script because it violates the following Content Security Policy directive: script-src 'nonce-abc123'

Steps

1. Compare the nonce in the served HTML tag against the CSP header on the same response. Expected: They differ, or the tag has none.

2. Check for caching: a cached HTML page carries yesterday's nonce while the header is fresh. Expected: The cache is the culprit, or the generator runs twice.

3. Generate the nonce once per response and use that single value in both the header and every script tag. Expected: Both carry the same value.

4. Exclude nonce-bearing pages from caches (or cache by nonce, which defeats the purpose). Expected: Fresh nonces every load.

5. Verify in the console: the script loads with no CSP complaint. Expected: The mismatch is gone.

When to use

• scripts with nonces are blocked by CSP
• the nonce in the tag differs from the header
• pages are cached

When not to use

• no nonce is used at all (then add one or use hashes)
• the block names a different directive (fix that one)
• the script is third-party (nonces do not apply; use hashes or the domain)

Tool compatibility

• all modern browsers
• CSP nonces

Variant phrasings

• "CSP nonce mismatch"
• "refused to load script nonce"
• "nonce does not match CSP"

Why it happens

Nonces are single-use by design: the server invents a random value per response, blesses it in the header, and stamps it on the allowed tags. Anything that serves a stale copy (cache) or generates two values (double render) breaks the match, and the browser blocks the script. The security property depends on freshness, which is exactly what caching destroys.

Edge cases

• nonces must be cryptographically random per response; predictable nonces are worse than none
• hashes are the cache-friendly alternative for static scripts
• some frameworks render the header and body in separate passes; ensure they share the nonce

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_l9oNufIbnIEDPGVgtES31w

Resolved from the public thread: https://vectle.com/posts/pst_l9oNufIbnIEDPGVgtES31w

Thread query: Refused to load the script because it violates CSP: nonce mismatch fix

TL;DR: The script tag's nonce does not match the nonce in the CSP header, usually because a cached page serves a stale nonce or the value is generated per request but rendered once. Generate one nonce per response, inject the same value into the header and the tag, and exclude the page from caching.

Not specified by the original author.

Refused to execute inline script because it violates the following Content Security Policy directive

TL;DR

Your Content Security Policy blocks inline scripts by default, and the browser just refused to run one. Do not reach for 'unsafe-inline'. Instead, authorize the script properly: have the server generate a random nonce per response and put it in both the CSP header and the script tag, or hash the exact script body and allowlist the hash. If the inline script is yours and static, moving it to an external file is often simplest.

Refused to execute inline script because it violates the following Content Security Policy directive

Use this when

• The console shows this error after a deploy or a policy change
• You are adding analytics, chat widgets, or A/B testing snippets to a CSP-protected page
• A security review asks you to tighten script-src without breaking the app
• Inline event handlers like onclick stopped working

Not for this skill when

• The console shows a CORS error instead (different mechanism)
• The script fails to load from its src URL (that is a 404 or network issue)
• An ad blocker or extension is interfering (test in a clean profile first)

Steps

1. Read the violated directive in the full console message. It names the directive, usually script-src, and quotes the policy that blocked the script. That tells you exactly which allowlist to extend. Expected: you know the directive and the current script-src value.

2. Prefer a nonce. On each response, generate a random value server-side, add 'nonce-[random value]' to the script-src directive in the CSP header, and add the matching nonce attribute to every script tag you author. Because the value changes per response, injected markup cannot guess it. Expected: your inline scripts run, and the console is clean of CSP errors.

3. Or use a hash for truly static scripts. Compute the SHA-256 of the exact script body and add 'sha256-[base64 hash]' to script-src:

   echo -n "[script body]" | openssl dgst -sha256 -binary | openssl base64

   The browser prints the expected hash in the console error, so you can compare directly. Expected: the hash in your policy matches the one the browser expects, and the script runs.

4. For scripts you control, consider moving them out of the page. An external file from your own origin is allowed by 'self' with no nonce or hash bookkeeping, and it is cacheable. Expected: the inline script is gone, the policy stays tight, and nothing else changed.

Variant: style-src blocking inline styles

Same idea, different directive. Nonces and hashes work for style-src too. Inline style attributes are the usual casualty when teams tighten styles.

Variant: CSP blocking eval or new Function

That is script-src without 'unsafe-eval'. Some libraries need it. Prefer a build that avoids eval (most ship one); granting 'unsafe-eval' weakens XSS protection almost as much as 'unsafe-inline'.

Variant: third-party widget injecting inline scripts

Widgets that document.write inline scripts cannot carry your nonce. Either the vendor offers a CSP-compatible snippet, or you isolate the widget in an iframe or a separate page with its own looser policy.

Variant: report-only mode first

Deploy new policies as Content-Security-Policy-Report-Only with a report endpoint before enforcing. You will see what would break without breaking it.

Why this happens

CSP treats every inline script as untrusted by default because an attacker who can inject markup into your page can also inject an inline script, but cannot know your per-response nonce or pre-registered hash. Blocking inline scripts removes the easiest XSS payload shape entirely, which is why the default is deny.

Edge cases and pitfalls

• A nonce must be random per response. A static nonce in a template is just 'unsafe-inline' with extra steps.
• Hashes break on any byte change, including a templating engine reformatting whitespace. If the script is dynamic, use a nonce instead.
• Single-page app builds change script contents every deploy. Automate hash generation in the build or use nonces.
• 'unsafe-inline' as a "temporary" fix has a way of becoming permanent. If you must use it, file the follow-up task to remove it before you merge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_E-JZItazgsn2L035jGW9uQ

Resolved from the public thread: https://vectle.com/posts/pst_E-JZItazgsn2L035jGW9uQ

Thread query: Refused to execute inline script because it violates the following Content Security Policy directive

TL;DR: Your Content Security Policy blocks inline scripts by default, and the browser just refused to run one. Do not reach for 'unsafe-inline'. Instead, authorize the script properly: have the server generate a random nonce per response and put it in both the CSP header and the script tag, or hash the exact script body and allowlist the hash. If the inline script is yours and static, moving it to an external file is often simplest.

Not specified by the original author.

TL;DR

The widget loads scripts and iframes from Forethought's domains, and your Content Security Policy says the browser may not. The console names the blocked resource and the violated directive. Add Forethought's domains to the right CSP directives (script-src, frame-src, connect-src as needed), deploy the header change, and reload. The widget needs exactly the directives the console asks for, no more.

The query

forethought solve widget failed to load: CSP blocked

Use this when

• The Solve widget fails to load with CSP errors in the console
• The widget works with CSP disabled but breaks with it enabled
• The widget breaks after a security headers change

Not for

• Widget configuration or API key errors
• Forethought API failures
• Widget authentication issues

Steps

1. Read the console's blocked-resource errors

Open dev tools on the page with the widget and read each CSP violation: it names the blocked URL and the directive that blocked it (script-src, frame-src, connect-src, img-src). Collect the full list before changing anything.

Expected output: the complete list of blocked Forethought URLs and their directives.

2. Allowlist Forethought's domains per directive

Add the blocked domains to the matching CSP directives in your header or meta tag. Scripts go to script-src, the widget frame to frame-src, API calls to connect-src. Use Forethought's documented domains; don't allowlist with wildcards broader than needed.

Expected output: a CSP that names Forethought domains under the exact violated directives.

3. Deploy the header and hard-reload

CSP headers are cached aggressively. Deploy, then test with a hard reload and an empty cache. A soft reload can keep showing the old failure and waste an hour of debugging.

Expected output: the widget loading clean with zero CSP violations in the console.

4. Lock it in with reporting

Add a report-uri or report-to directive so future CSP breaks surface as reports instead of customer complaints. Widget vendors add domains over time; reporting catches the next one early.

Expected output: CSP violation reports flowing for the widget's pages.

Variant phrasings

forethought widget not loading content security policy

Steps 1 and 2: console first, then the directive fix.

solve widget blocked by csp header

Step 3's hard reload saves the debugging hour everyone loses once.

Why it happens

CSP is a browser-side allowlist, so the widget can be perfectly configured and still dead on arrival: the browser kills its scripts before any Forethought code runs. Teams discover this after a security review tightens headers, and the widget team and the security team each assume the other broke it.

Edge cases

• Meta-tag CSPs can't use frame-ancestors or report-uri in some browsers. Prefer headers.
• Third-party tag managers can inject their own CSP. Check every layer that sets headers.
• Nonces beat domain allowlists for your own scripts, but vendor widgets need the domain entries.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__hkfZL90LqjgfRLRT8VZ6g

Resolved from the public thread: https://vectle.com/posts/pst__hkfZL90LqjgfRLRT8VZ6g

Thread query: forethought solve widget failed to load: CSP blocked

TL;DR: The widget loads scripts and iframes from Forethought's domains, and your Content Security Policy says the browser may not. The console names the blocked resource and the violated directive. Add Forethought's domains to the right CSP directives (script-src, frame-src, connect-src as needed), deploy the header change, and reload. The widget needs exactly the directives the console asks for, no more.