Refused to connect because it violates the document's Content Security Policy

Not specified by the original author.

Refused to connect because it violates the document's Content Security Policy

TL;DR

The page's Content Security Policy does not allow connections to that endpoint, so the browser blocked the fetch. Add the endpoint's origin to the connect-src directive. The console names the violated directive; extend that directive.

Refused to connect to 'https://api.example.com/data' because it violates the document's Content Security Policy.

Steps

1. Read the console message: it names the violated directive (usually connect-src). Expected: You know which directive to extend.

2. Find where the policy is set: the Content-Security-Policy header or the meta tag. Expected: The policy source is located.

3. Add the endpoint's origin to that directive (e.g. connect-src 'self' https://api.example.com). Expected: The directive allows the endpoint.

4. Redeploy and retry the exact blocked request. Expected: The console is clean.

5. Keep the policy tight: add only the origins the app needs, never a blanket wildcard. Expected: The policy stays meaningful.

When to use

• fetch or XHR is blocked by CSP
• the console names a violated directive
• a new API endpoint was added

When not to use

• the block is on scripts or styles (different directive)
• there is no CSP at all (check for a different blocker)
• the endpoint is genuinely untrusted (do not add it)

Tool compatibility

• all modern browsers
• CSP Level 2/3

Variant phrasings

• "refused to connect CSP"
• "content security policy connect-src"
• "CSP blocked fetch"

Why it happens

CSP's connect-src governs where scripts may send network requests. When the frontend gains a new API endpoint that the policy predates, the browser blocks it. The console message is precise about the violated directive, which makes this a lookup-and-extend fix rather than a debugging session.

Edge cases

• meta-tag policies cannot use some directives (frame-ancestors, report-uri); prefer the header
• report-only mode logs without blocking; use it to preview policy changes
• websockets need the ws: or wss: scheme in connect-src explicitly

Provenance

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

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

Thread query: Refused to connect because it violates the document's Content Security Policy

TL;DR: The page's Content Security Policy does not allow connections to that endpoint, so the browser blocked the fetch. Add the endpoint's origin to the connect-src directive. The console names the violated directive; extend that directive.

Not specified by the original author.

fullstory network capture blocked csp connect-src error

TL;DR

The browser console's CSP violation names the blocked FullStory URL. Add FullStory's capture domains to connect-src in your CSP header (and the snippet domain to script-src if the snippet itself is blocked), reload, and confirm the violations stop and network data appears in FullStory sessions.

fullstory network capture blocked csp connect-src error

Use this when

• FullStory sessions lack network request data
• Browser console shows CSP violations for FullStory URLs
• The issue started after tightening the Content Security Policy

Not for this skill when

• The FullStory snippet itself failing to load (script-src, different fix)
• Adblockers preventing FullStory entirely (client environment)
• FullStory recording disabled in project settings

Steps

Step 1: Read the CSP violation

Open the browser console and copy the exact blocked URL from the CSP violation. Expected: you know precisely which FullStory endpoint is blocked.

Step 2: Update connect-src

Add FullStory's capture domains to the connect-src directive in your CSP header or meta tag. Expected: the policy explicitly permits those endpoints.

Step 3: Check script-src too

If the snippet itself is blocked, add its domain to script-src as well. Expected: both the loader and its network calls are permitted.

Step 4: Reload and re-test

Hard reload and reproduce the session. Expected: no CSP violations appear in the console.

Step 5: Verify capture in FullStory

Open a new session in FullStory and confirm network request data is present. Expected: the waterfall shows captured requests.

Tool compatibility

FullStory session replay; Content Security Policy headers; browser developer console.

Variant phrasings

Variant 1

fullstory csp connect-src blocked

Variant 2

fullstory network capture not working content security policy

Variant 3

fullstory refused to connect csp violation

Why it happens

FullStory's network capture works by sending recorded request data from the browser to its own endpoints via XHR and beacons, which is exactly what a strict connect-src directive is designed to police. When security teams tighten CSP, often as part of a compliance push, FullStory keeps recording the page but silently loses the network waterfall, and nobody notices until someone needs that data for debugging. The console violation is the giveaway, but it only appears in the browser of whoever looks. The fix is policy surgery: permit the specific FullStory domains rather than loosening connect-src broadly, which would defeat the purpose of the policy.

Edge cases / pitfalls

• Report-only mode is the safe way to test CSP changes; enforce mode breaks things silently for users.
• Nonce-based CSP needs the FullStory snippet to carry the nonce; check the integration docs for the pattern.
• Multiple CSP headers or meta tags combine restrictively; check for duplicates before editing one.

Provenance

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

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

Thread query: fullstory network capture blocked csp connect-src error

TL;DR: The browser console's CSP violation names the blocked FullStory URL. Add FullStory's capture domains to connect-src in your CSP header (and the snippet domain to script-src if the snippet itself is blocked), reload, and confirm the violations stop and network data appears in FullStory sessions.

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.