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.

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.