WebUtils
EN

Developer Workflow

Analyze a Content-Security-Policy header

Break down a Content-Security-Policy header into directives and source expressions before changing script, image, frame, or reporting rules.

Open Csp Header Analyzer

Problem

Content-Security-Policy headers become hard to reason about as soon as they include several directives, third-party hosts, report endpoints, and exception tokens. A blocked script, missing image, failed frame, or noisy report-only rollout can come from one directive inside a long single-line header.

When to use this

  • A browser console reports a CSP violation and you need to find the directive that blocked the resource.
  • A deployment changes script, image, frame, connect, or reporting rules and the policy needs a readable review.
  • A policy includes risky source expressions such as wildcard hosts, unsafe-inline, unsafe-eval, data:, or plain HTTP sources.
  • You need to compare an enforced CSP header with a report-only header before promoting it.

Steps

  1. Step 1

    Copy the exact CSP header value

    Copy the Content-Security-Policy or Content-Security-Policy-Report-Only header from DevTools, curl, CDN logs, or deployment output. Keep the full value, including semicolons.

  2. Step 2

    Normalize directives before editing

    Paste the header into CSP Header Analyzer so each directive and source expression is split into a readable summary without changing the original copied values.

  3. Step 3

    Check risky source expressions

    Review findings for wildcard sources, unsafe-inline, unsafe-eval, data: sources, HTTP sources, duplicate directives, and missing default-src fallback.

  4. Step 4

    Trace the browser symptom to a directive

    Map blocked scripts to script-src, failed images to img-src, blocked API calls to connect-src, and embedding issues to frame-src or frame-ancestors.

  5. Step 5

    Review the surrounding response headers

    Use Security Headers Checker or HTTP Header Parser when you need to inspect CSP beside HSTS, nosniff, frame protection, cache, and CORS headers.

Example

Review a CSP that allows third-party scripts

Input

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com 'unsafe-inline'; img-src https: data:; connect-src 'self' https://api.example.com; frame-ancestors 'none'

Output

Directives: 5
Source expressions: 9
Findings: unsafe-inline in script-src, data: source in img-src
Normalized policy: default-src, script-src, img-src, connect-src, frame-ancestors

Common mistakes

Editing without preserving the full header

Copying only one directive can hide the fallback behavior from default-src or miss duplicate directives later in the header.

Assuming report-only blocks resources

Content-Security-Policy-Report-Only reports violations without enforcing them. Compare the header name before diagnosing a blocked request.

Removing a source before mapping the dependency

Third-party scripts, images, analytics, fonts, and API calls may depend on specific directives. Trace the blocked URL before tightening a rule.

FAQ

Can this prove my CSP is secure?

No. It can make a CSP easier to review and highlight common risky patterns, but it cannot certify that the policy is complete or secure for your app.

What is the difference between CSP and report-only CSP?

Content-Security-Policy enforces browser restrictions. Content-Security-Policy-Report-Only reports violations without blocking resources, which is useful before rollout.

Why does one blocked resource point to another directive?

Browsers choose directives by resource type. A blocked API request usually maps to connect-src, while a blocked image maps to img-src and an embedded page maps to frame-src or frame-ancestors.