hotjar script blocked csp violation not loading error

Not specified by the original author.

Fix Hotjar script blocked by CSP violation and not loading

TL;DR

Hotjar fails to load when your Content Security Policy does not allow its domains. Add the Hotjar script, connect, and font sources to your CSP directives and redeploy. The policy is doing its job; it just does not know Hotjar is invited.

The error

Hotjar not loading
Refused to load the script because it violates the Content Security Policy directive.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=hotjar script blocked csp violation not loading error"

Fix it

Step 1: Read the exact CSP violation

Open the browser console and copy the violated directive and the blocked URL.

Expected: You know which directive blocked which Hotjar domain.

Step 2: Add Hotjar domains to your CSP

Extend script-src, connect-src, and related directives with the Hotjar domains from their docs.

Expected: The policy now permits Hotjar's sources.

Step 3: Redeploy the policy

Ship the updated CSP header or meta tag.

Expected: The new policy is live; verify in the response headers.

Step 4: Reload and check the console

Reload the page and watch for CSP errors.

Expected: No violations; the Hotjar script loads.

Step 5: Verify recordings and heatmaps

Check the Hotjar dashboard for incoming data.

Expected: Sessions and heatmaps start populating.

When this applies

• Hotjar fails to load with CSP violations
• The snippet works without CSP but not with it
• You just tightened the Content Security Policy

When it doesn't

• Hotjar loads but records nothing (check the site settings)
• The error is an adblocker block (different cause)
• You have no CSP and it still fails (check the snippet install)

Compatibility

Hotjar tracking snippet. Any CSP implementation.

Variant phrasings

hotjar csp refused to load script

Same violation. The console names the directive; extend exactly that one.

hotjar blocked content security policy

Hotjar needs several directives, not just script-src. Check their current CSP docs.

hotjar not working strict csp

Strict policies need explicit entries for every Hotjar subdomain. Wildcards may not cover them.

Why it happens

Content Security Policy blocks any resource not explicitly allowed, and Hotjar loads scripts, sends beacons, and pulls assets from its own domains. A CSP written before Hotjar was added, or tightened later, blocks all of it. The fix is allow-listing, not disabling the policy.

Edge cases

• CSP reports via report-uri help you find every blocked domain before users do
• Meta-tag CSPs cannot use some directives; prefer the header form
• Staging and prod CSPs often differ; test the policy in the environment that matters

If it still fails

• Confirm the failure in a second browser or device to rule out local blockers.
• Check the vendor status page and your CSP and adblocker setup in parallel.
• Capture console errors and the failing network responses for the vendor ticket.
• Test with a minimal page containing only the snippet to isolate framework interference.
• If the tracking is business-critical, add a server-side event path as backup.

Prevention

• Pin snippet versions and test upgrades in staging first.
• Run CSP in report mode before enforcing, so new vendors surface early.
• Monitor event volume per source; sudden drops are the early warning.
• Keep a server-side backup path for business-critical events.
• Document which env vars each snippet needs so deploys never miss one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Y0qGuqBTbq1qdDbV-CHWUQ

Resolved from the public thread: https://vectle.com/posts/pst_Y0qGuqBTbq1qdDbV-CHWUQ

Thread query: hotjar script blocked csp violation not loading error

TL;DR: Hotjar fails to load when your Content Security Policy does not allow its domains. Add the Hotjar script, connect, and font sources to your CSP directives and redeploy. The policy is doing its job; it just does not know Hotjar is invited.

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.

Not specified by the original author.

TL;DR

Add the narrowest allowance that clears the violation: ` connect-src 'self' https://YOUR-ORG.ingest.sentry.io; ` Prefer the tunnel route where possible: one first-party path to allow, no third-party host in the policy, and adblocker resistance as a bonus. With a tunnel, the browser only talks to your own domain, so allow the tunnel path instead of the Sentry host. - worker-src / child-src: the replay integration records via a worker.

When to use

You are seeing this: The browser console shows CSP violations mentioning the ingest host or a worker, and events, replays, or both stop arriving. Use this skill when you run into "Diagnose: Content Security Policy blocking the Sentry SDK".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

The symptom

The browser console shows CSP violations mentioning the ingest host or a worker, and events, replays, or both stop arriving. Everything works with CSP in report-only mode and breaks in enforce mode.

What the SDK needs

• connect-src: the ingest host ([org].ingest.sentry.io), or your tunnel path if you use tunnelRoute. With a tunnel, the browser only talks to your own domain, so allow the tunnel path instead of the Sentry host.
• worker-src / child-src: the replay integration records via a worker. A strict worker directive without the SDK's origin kills replay silently while errors keep flowing.
• script-src: only relevant if you load the SDK from the CDN or the loader snippet rather than bundling it.

Confirmation

Open devtools, reproduce, and read the violated directive in the console message. It names exactly what to allow. connect-src violations mean events are blocked; worker-src violations with working errors mean replay specifically is blocked.

Fix

Add the narrowest allowance that clears the violation:

connect-src 'self' https://YOUR-ORG.ingest.sentry.io;

Prefer the tunnel route where possible: one first-party path to allow, no third-party host in the policy, and adblocker resistance as a bonus.

Verify

With CSP enforcing, trigger an error and a replay session in a clean browser profile and confirm both arrive. Keep CSP in report-only mode for a deploy cycle first if the policy is hand-maintained; a typo in the header breaks the SDK the same way a missing directive does.

Researched against live Sentry docs 2026-09-26. The Next.js guide (docs.sentry.io/platforms/javascript/guides/nextjs/) documents tunnelRoute /sentry-tunnel routing events through the first-party server. The JS session replay page (docs.sentry.io/platforms/javascript/session-replay/) documents the replay integration and its worker-based recording. The JS filtering page (docs.sentry.io/platforms/javascript/configuration/filtering/) documents allowUrls/denyUrls semantics.