Start here
Before You Fix It: What This Check Means
CSP is a containment control for script execution and one of the strongest mitigations against injection damage. In plain terms, this tells you whether visitors are protected by the security setup you intend to run in production. Scavo inspects response headers for.
Why this matters in practice: weak settings here can increase breach risk and incident blast radius before teams notice.
How to use this result: treat this as directional evidence, not final truth. A crawl snapshot cannot prove every route, subdomain, or transient edge rule is consistently configured. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Start from strict baseline: `default-src 'self'; object-src 'none'; base-uri 'self';`. Finally, re-scan the same URL to confirm the result improves.
TL;DR: Your CSP header is missing or misconfigured, making your site vulnerable to cross-site scripting (XSS) attacks.
XSS accounts for approximately 20% of reported web vulnerabilities across all industries (OWASP, 2024). A strong CSP is your primary defence — yet only 21.9% of sites have adopted CSP (HTTP Archive, 2025), and 91% of those still include unsafe-inline, making the policy ineffective. Without CSP, a single compromised third-party script or input field can steal user data, inject malware, or deface your site.
What Scavo checks (plain English)
Scavo inspects response headers for:
Content-Security-Policy(enforced)Content-Security-Policy-Report-Only
Decision logic in this check:
- Info: only report-only policy exists (no enforcement)
- Warning: no CSP header detected
- Fail: CSP present but missing core baseline (
default-srcandscript-srcabsent with hardening gaps) - Warning: risky patterns like
'unsafe-inline','unsafe-eval', or wildcard*in key script/style directives - Warning: enforced CSP exists but missing hardening directives (for example
object-src,base-uri) - Pass: enforced CSP with baseline hardening and no risky patterns detected
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for content_security_policy, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
content_security_policy - Category:
SECURITY
Why fixing this matters
CSP is not a silver bullet, but it meaningfully reduces exploitability when script injection bugs occur. Weak or permissive directives can leave teams with false confidence while still allowing risky execution paths.
A well-maintained CSP also improves change control: new third-party scripts and inline behavior become explicit decisions rather than accidental drift.
Common reasons this check flags
- Policy deployed in report-only mode and never enforced.
- Legacy inline/eval dependencies left in production.
- Wildcard source allowances in
script-src/style-src. - Missing baseline directives after incremental policy edits.
If you are not technical
- Ask whether CSP is enforced or report-only.
- Require a short list of known exceptions and why they exist.
- Prioritize reducing unsafe directives on critical public pages.
- Re-scan and confirm risk patterns are removed.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Content Security Policy (content_security_policy). Please enforce CSP (not only report-only), remove risky script directives (unsafe-inline/unsafe-eval/wildcards where possible), and ensure baseline hardening directives are present.If you are technical
- Start from strict baseline:
default-src 'self'; object-src 'none'; base-uri 'self';. - Replace broad inline/eval dependencies with nonce/hash-based patterns where feasible.
- Minimize wildcard origins in script/style directives.
- Use report collection to tune policy safely before full enforcement.
- Keep policy changes versioned and reviewed.
How to verify
- Inspect production response headers for enforced CSP.
- Confirm risky tokens are absent or intentionally scoped.
- Validate core directives (
default-srcorscript-src, plusobject-src,base-uri). - Re-run Scavo and verify it moves to pass or lower-risk warning.
What this scan cannot confirm
- It does not prove your app is free of XSS vulnerabilities.
- It does not validate every advanced CSP optimization pattern.
- It does not check report endpoint quality or triage workflow.
Owner checklist
- [ ] Assign owner for CSP governance and exception lifecycle.
- [ ] Track/report CSP violations and review regularly.
- [ ] Version-control CSP with security review gates.
- [ ] Re-audit policy after frontend framework or third-party script changes.
FAQ
Is report-only mode enough?
It is useful during rollout, but not a final state for protection.
Do we have to remove all inline scripts immediately?
Not always in one step. Use phased hardening with nonces/hashes and measured rollout.
Are wildcards always bad?
They are high risk in key directives and should be minimized or replaced with explicit origins.
What should we fix first?
Enforcement first, then remove unsafe directives and tighten source lists.
Sources
- MDN: Content Security Policy (CSP)
- MDN: CSP header reference
- OWASP: Content Security Policy Cheat Sheet
- W3C CSP Level 3 spec
Need a phased CSP hardening plan that avoids breaking production? Send support your current policy and script inventory.
