Content Security Policy, without the guesswork
Your page invites scripts, images and other resources into the browser. Content Security Policy (CSP) sets rules for what is allowed to load or run. A useful policy starts with knowing your guests.
A safer path from report-only to enforcement.
A guest list needs more than a front door
A missing or permissive CSP finding is a prompt to review browser defences. It does not establish that someone can exploit your site. A present header can still contain rules that offer little protection.
The guest-list metaphor has a limit: trusting a whole script host can admit more code than you intended. Nonces or hashes can identify approved scripts more precisely. CSP adds a layer against attacks such as cross-site scripting; secure code and safe handling of untrusted input still matter.
Directives
Rules such as script-src and img-src cover different resource types. default-src supplies a fallback for many fetch directives, but not every CSP directive.
Nonces or hashes
A nonce must be unpredictable and fresh for each response. A hash identifies specific script content and must change when that content changes.
Report-only
Try a proposed policy without blocking resources. Configure reporting and inspect real journeys before deciding it is ready to enforce.
Build the guest list in four moves
Work with whoever owns your application and response headers. Keep the previous working configuration available for rollback.
Understand → test → change → recheckMap the journeys that matter
Inventory your own code and third-party dependencies across representative pages, including logged-in flows you can test privately. Note scripts, styles, frames, fonts and connection destinations.
Ready when You can explain why each dependency is needed.
Rehearse with report-only
Test a proposed Content-Security-Policy-Report-Only header in a controlled environment, then monitor representative use. Set up a reporting destination deliberately; reports can contain sensitive URL details, so limit access and retention.
Ready when You have exercised real journeys and investigated the reports.
Fix the cause, then narrow the rules
Remove unnecessary inline handlers and risky evaluation where possible. Choose a nonce or hash approach that fits how your pages are delivered. Review inherited defaults, framing rules and any exceptions with the application owner.
Ready when The policy permits necessary behaviour for a reason.
Enforce gradually and keep watching
After testing, move the reviewed policy into enforcement through your normal release process. Watch errors and essential journeys, and roll back if needed. Repeat the review when dependencies or page templates change.
Ready when The site still works and the intended policy reaches its responses.
What CVE Scanner can see
Public beta · validation ongoingWithin the lens
Selected anonymous HTML responses: CSP presence, supported directive fallbacks, nonce/hash settings and intersecting policies, alongside other browser-policy observations.
Beyond the lens
No JavaScript execution or browser-confirmed CSP bypass testing. Logged-in pages, other unselected routes and complete policy quality are outside this evidence.
Use the reported response and directive as the starting point. Verify the effective headers in a browser and test your own critical journeys before changing enforcement.
A couple of useful questions
Does report-only protect visitors?
The proposed report-only policy does not block violations. An existing enforced policy can remain in place while you test a new report-only policy. Treat reporting as a rehearsal, not proof of protection.
Can I add a second policy to loosen the first?
Multiple enforced policies apply together. A second policy does not simply overwrite or loosen the first. Check headers added by the application, proxy and hosting layer so you understand the combined restrictions.
Read a little deeper
Primary guidance for the next conversation with your developer or administrator. References open in a new tab.
- MDN: Content Security Policy
Directives, nonces, hashes and the limits of host allowlists.
- MDN: Report-only response header
How to observe a proposed policy and configure reporting.
- OWASP: CSP implementation guidance
Deployment choices and defence in depth.