Browser CSP Violations — Content Security Policy Error Guide
About Browser CSP Violations
Fix Content Security Policy (CSP) violation errors including 'Refused to execute inline script', blocked resource loading, and CSP header misconfiguration. This guide covers everything you need to know about this topic, including common causes, step-by-step solutions, and answers to frequently asked questions.
Here are the key things to understand: CSP is an HTTP header that controls which resources a page can load and execute. CSP violations appear in the browser console as 'Refused to...' messages. Common directives: script-src, style-src, img-src, connect-src, font-src, frame-src. Inline scripts and eval() are blocked by default unless explicitly allowed. CSP report-uri or report-to sends violation reports to a specified endpoint. Understanding these fundamentals will help you diagnose and resolve this issue more effectively.
The most common reasons this occurs include: CSP policy blocking legitimate scripts or resources (too restrictive policy). Inline scripts blocked by script-src not including 'unsafe-inline' or nonces. Third-party resources (CDN, analytics, ads) not listed in the CSP. eval() used in code but not allowed by script-src. Browser extension injecting scripts that violate the page's CSP. Identifying the root cause is the first step toward finding the right solution.
To resolve this, follow these recommended steps: Read the console error — it specifies which directive blocked which resource. Add the resource origin to the appropriate CSP directive (e.g., script-src https://cdn.example.com). For inline scripts: use nonces (script-src 'nonce-RANDOM') or hashes ('sha256-HASH'). Test with Content-Security-Policy-Report-Only header to test without blocking. Use CSP Evaluator (csp-evaluator.withgoogle.com) to check your policy for issues. If these steps do not resolve the issue, consider consulting additional resources or a qualified professional.
This article is part of our Browser Errors collection on Error Codes Wiki. We provide comprehensive, up-to-date information to help you find solutions quickly.
Quick Answer
Should I use 'unsafe-inline' in script-src?
Avoid it if possible — it weakens CSP significantly. Use nonces or hashes instead. 'unsafe-inline' allows any inline script including injected XSS.
Overview
Fix Content Security Policy (CSP) violation errors including 'Refused to execute inline script', blocked resource loading, and CSP header misconfiguration.
Key Details
- CSP is an HTTP header that controls which resources a page can load and execute
- CSP violations appear in the browser console as 'Refused to...' messages
- Common directives: script-src, style-src, img-src, connect-src, font-src, frame-src
- Inline scripts and eval() are blocked by default unless explicitly allowed
- CSP report-uri or report-to sends violation reports to a specified endpoint
Common Causes
- CSP policy blocking legitimate scripts or resources (too restrictive policy)
- Inline scripts blocked by script-src not including 'unsafe-inline' or nonces
- Third-party resources (CDN, analytics, ads) not listed in the CSP
- eval() used in code but not allowed by script-src
- Browser extension injecting scripts that violate the page's CSP
Steps
- 1Read the console error — it specifies which directive blocked which resource
- 2Add the resource origin to the appropriate CSP directive (e.g., script-src https://cdn.example.com)
- 3For inline scripts: use nonces (script-src 'nonce-RANDOM') or hashes ('sha256-HASH')
- 4Test with Content-Security-Policy-Report-Only header to test without blocking
- 5Use CSP Evaluator (csp-evaluator.withgoogle.com) to check your policy for issues