How to Fix Content-Security-Policy Errors

A Content-Security-Policy error in the browser console usually means your policy is working — it blocked something the page tried to load. The challenge is deciding whether that something was an attack or a legitimate script you forgot to allow. This guide walks through reading CSP violations, fixing the common causes, and rolling out changes without taking your site offline.

Reading a CSP violation report

Open dev tools and look for messages mentioning Content-Security-Policy or blocked-uri. Each report tells you which directive failed (script-src, style-src, img-src), what was blocked, and which page triggered it. That combination is your checklist: add the blocked origin to the right directive, or remove the resource if it should not be there.

• `blocked-uri` — the resource that was refused. Often a third-party analytics or font domain.
• `violated-directive` — which part of your policy rejected it, such as script-src 'self'.
• `source-file` and line number — where the offending tag or inline script lives in your markup.
• `effective-directive` — the directive the browser actually applied, useful when policies inherit from default-src.

The fixes that solve most errors

1. 1Add missing third-party origins to the correct directive — analytics to script-src, fonts to font-src, images to img-src.
2. 2Replace inline scripts with external files, or use a nonce or hash if inline code is unavoidable.
3. 3Move from 'unsafe-inline' for styles only when needed; prefer external stylesheets for production policies.
4. 4Use `Content-Security-Policy-Report-Only` while testing so visitors are not blocked during refinement.

Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;

When the error is not your policy

Sometimes the blocked resource is malware injected by a compromised plugin or a supply-chain script you no longer trust. If a violation points at an origin you do not recognise, treat it as a security finding — remove the script and investigate how it appeared rather than whitelisting it.

After each change, rescan your live headers with a security scan to confirm the enforced policy matches what you intended. PatchPings flags risky directives like broad wildcards and missing object-src 'none', then generates stack-specific snippets you can paste into Nginx, Apache or Cloudflare.

CSP errors are tedious but predictable. Read the violation, allow only what you trust, test in report-only mode, enforce, and verify. If you are still designing the policy, start with the CSP staged setup guide. Done in that order, you close XSS exposure without the broken-page stories that scare teams away from CSP in the first place. Download PatchPings to scan headers from your phone and get AI-written fixes for every gap.