EngineeringScoreEnforce the existing Content-Security-Policy
Content-Security-Policy-Report-Only runs the exact same policy as an enforcing CSP, but only logs violations instead of blocking them. It exists so a team can watch a real policy against real traffic before it can break anything. A site with this header live has already done the hard part (writing the policy and validating it); the browser just is not acting on it yet.
Why it matters
A report-only policy only logs violations; it does not stop a malicious script from running. The hard part (defining the policy and watching it against real traffic to catch breakage) is already done, so the remaining risk is closed by a one-line header rename, not a redesign.
How to fix
- 1 Confirm no unexpected violations are still appearing for real traffic under the report-only policy.
- 2 Rename the response header from Content-Security-Policy-Report-Only to Content-Security-Policy.
- 3 Redeploy and verify the enforcing header is present and the site still functions.
Common mistakes
- Leaving a policy in Report-Only indefinitely because "it works": a policy that only reports never actually stops an injected script from running.
- Renaming the header to enforcing mode without first checking recent violation reports, missing a legitimate script that would break in production.
- Assuming Report-Only counts as having CSP for compliance or audit purposes: it provides visibility, not protection.
How to verify
- 1 Review the violations captured for the report-only policy and confirm nothing legitimate is still being flagged.
- 2 Rename the response header to Content-Security-Policy and confirm the site still functions end to end.
- 3 Inspect response headers afterward and confirm Content-Security-Policy-Report-Only is gone and Content-Security-Policy is present.
Related checks
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.