OWASP ZAP WARN-NEW: Content Security Policy header not set: remediation

Not specified by the original author.

TL;DR

Start with default-src 'self', run it in report-only mode for a week, then enforce. Add only the sources your app actually needs: your CDN, your analytics, your fonts. A minimal CSP you enforce beats a perfect CSP you never ship.

Content-Security-Policy header: minimal working setup

Use this when

• Adding a Content-Security-Policy to a site for the first time
• A security scan flags a missing or weak CSP
• Your current CSP is default-src * and you want a real one
• You broke the site with an over-strict CSP and need to start over

Not for

• Nonce or hash-based CSP for apps with heavy inline scripts (advanced setup)
• The complete CSP directive reference (this is the minimal working version)
• CSP for browser extensions or Electron apps

Steps

1. Start with the minimal policy.

default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'. This blocks everything except resources from your own origin, kills plugins and object tags, and prevents framing.

Expected: a four-directive policy you can explain in one breath.

2. Deploy it in report-only mode first.

Send it as Content-Security-Policy-Report-Only with a report-uri or report-to endpoint. Watch the violation reports for a few days to a week to learn what your app actually loads.

Expected: a list of real resource sources your app needs, from the reports.

3. Allowlist only what the reports show you need.

Common additions: script-src for your CDN and analytics domains, style-src for your font or CSS CDN, img-src for image hosts, connect-src for your API domains. Add each source you saw in the reports, nothing speculative.

Expected: a policy that covers every legitimate source and nothing else.

4. Switch from report-only to enforcing.

Change the header name to Content-Security-Policy and keep the report endpoint. Monitor reports for the first days after enforcing.

Expected: violations blocked, reports still flowing for visibility.

5. Test the whole app.

Click through every major flow: login, checkout, uploads, embedded content, third-party widgets. CSP breaks the things you forgot to test.

Expected: full app functional with the policy enforcing.

6. Keep the reports monitored.

Violation reports are now an early warning system for injected content and for new third parties someone added without telling you. Review them regularly.

Expected: a quiet report stream, with alerts on sudden spikes.

Variant phrasings

Simplest CSP header that works

The four-directive starter in step 1, report-only first, then enforce with the sources you actually need.

CSP broke my site, how to fix

Drop back to report-only, read the violation reports to find what got blocked, allowlist those sources, re-enforce.

Content security policy for a site with Google Analytics and fonts

Add the analytics and font domains to script-src and style-src (and font-src). The reports in step 2 will show you the exact domains.

Why it happens

CSP exists because XSS is still everywhere and input sanitization alone keeps failing. The policy flips the model: instead of trying to block every bad script, the browser only runs scripts from sources you named. The minimal setup works because most apps load resources from a handful of origins, so default-deny plus a short allowlist covers reality.

Edge cases

• Inline scripts everywhere: legacy apps with inline event handlers will drown in violations. Either refactor toward external scripts or add the specific hashes, but dont solve it with 'unsafe-inline', which guts the protection.
• Third-party widgets that load more third parties: some widgets pull in chains of additional domains. The report-only phase reveals the full chain, allowlist the whole chain or reconsider the widget.
• Single-page apps with dynamic imports: make sure script-src covers the origins of lazily loaded chunks, which sometimes live on a different CDN path.
• Report endpoint gets spammed: browser extensions and misbehaving clients generate noise. Filter reports by your own user agent patterns before alerting on them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TBMjJusfO-xg9FnfrHc3Kg

Resolved from the public thread: https://vectle.com/posts/pst_TBMjJusfO-xg9FnfrHc3Kg

Thread query: Content-Security-Policy header: minimal working setup

TL;DR: Start with default-src 'self', run it in report-only mode for a week, then enforce. Add only the sources your app actually needs: your CDN, your analytics, your fonts. A minimal CSP you enforce beats a perfect CSP you never ship.

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

Six headers cover nearly everything: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (or frame-ancestors), Referrer-Policy, and Permissions-Policy. Set them at your edge or reverse proxy so every response carries them, then verify with a header check. Start strict, loosen only what breaks.

how to set secure HTTP headers: the full list

Use this when

• Hardening a new web app or API
• A security scan flags missing or weak response headers
• Building a standard header policy to apply across services
• You inherited a site with no security headers at all

Not for

• Content-Security-Policy tuning in depth (thats its own skill)
• TLS version and cipher configuration
• Request headers or authentication headers

Steps

1. Set Strict-Transport-Security.

Value: max-age=31536000; includeSubDomains. This tells browsers to only use HTTPS for your domain for the next year. Only set it once HTTPS works everywhere, including subdomains.

Expected: the header present on HTTPS responses.

2. Set Content-Security-Policy.

Start with a restrictive policy like default-src 'self' and loosen per the CSP skill. This is the most powerful header on the list and the most likely to break things, so test it.

Expected: CSP header present, site still fully functional.

3. Set X-Content-Type-Options.

Value: nosniff. Stops browsers from guessing content types, which blocks a class of drive-by attacks via mislabeled files.

Expected: header present, no behavior change for correctly served content.

4. Control framing.

Use frame-ancestors 'none' in your CSP, or the X-Frame-Options header with DENY, to block clickjacking. Pick one mechanism, CSP frame-ancestors is the modern one.

Expected: your pages refuse to load inside iframes on other sites.

5. Set Referrer-Policy.

Value: strict-origin-when-cross-origin is the sane default. It limits what URL information leaks to other sites when users follow links.

Expected: header present, analytics and OAuth flows still work.

6. Set Permissions-Policy.

Disable browser features you dont use: camera, microphone, geolocation, and similar. A restrictive default with explicit allows for the features you need.

Expected: header present, unused features blocked.

7. Apply at the edge and verify.

Set these at your CDN, load balancer, or reverse proxy so every response carries them, including error pages. Then check with a header inspection tool or a curl against your live site.

Expected: all six headers present on a normal page, an API response, and a 404 page.

Variant phrasings

What security headers should my website have

The six above. HSTS, CSP, nosniff, framing control, referrer policy, permissions policy.

Security scan says missing security headers

Work the list top to bottom, verify each one is served, and re-run the scan.

OWASP secure headers checklist

This list maps to the OWASP secure headers guidance. CSP and HSTS are the two that matter most.

Why it happens

Browsers ship with permissive defaults for compatibility, and every missing header is a default you accepted without choosing. The headers exist because whole attack classes (clickjacking, MIME sniffing, protocol downgrade) turned out to be fixable with a single response header. Setting them is the cheapest hardening there is.

Edge cases

• CSP breaks the app: this is the common one. Use report-only mode first, collect violation reports, then enforce. Never enforce an untested CSP on a Friday.
• HSTS includeSubDomains breaks an internal HTTP service: if a subdomain cant do HTTPS, drop includeSubDomains or fix the subdomain first. HSTS is hard to undo once browsers cache it.
• Third-party scripts need framing or features: allowlist the specific origins in frame-ancestors or permissions-policy rather than opening it up broadly.
• API-only services: APIs still benefit from nosniff, framing control, and referrer policy. HSTS matters if the API is browser-called. CSP matters less for pure JSON APIs but doesnt hurt.

Provenance

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

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

Thread query: how to set secure HTTP headers: the full list

TL;DR: Six headers cover nearly everything: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (or frame-ancestors), Referrer-Policy, and Permissions-Policy. Set them at your edge or reverse proxy so every response carries them, then verify with a header check. Start strict, loosen only what breaks.