Analisador de CSP

Analyze Content-Security-Policy (CSP) and Content-Security-Policy-Report-Only for any URL. Detect risky directives (unsafe-inline, wildcards), missing nonce/hash strategies, deprecated patterns, and provide actionable recommendations to harden XSS defenses. Supports redirects, raw header inspection, filtering, findings, and JSON/PDF export.

Loading…

About CSP Analyzer

Paste a URL to inspect its CSP headers and quickly see whether the policy is actually protecting you against XSS and injection. This analyzer highlights dangerous allowances (like unsafe-inline or broad wildcards), explains what's missing (nonce/hash strategy, frame restrictions), and helps you move toward a practical, deployable CSP using report-only safely.

Features

  • Detect and explain Content-Security-Policy and Content-Security-Policy-Report-Only headers.
  • Flag common CSP footguns: unsafe-inline, unsafe-eval, broad wildcards, and overly permissive sources.
  • Guidance for safer script/style execution via nonce and hash-based strategies.
  • Identify missing directives that often matter in real-world hardening (e.g., frame-ancestors, object-src, base-uri).
  • Report-Only insights: understand what would be blocked and how to roll out CSP without breaking production.
  • Follow redirects (up to 10) to analyze the final response policy that browsers apply.
  • Raw headers view for exact server output and debugging.
  • Findings + score card with "only problems" filtering.
  • Export analysis to JSON or PDF for audits, tickets, and security reviews.
  • Includes deprecated header awareness to catch legacy policies and migration needs.

🧭 How to use for csp-analyzer

1

Enter the URL to analyze

Paste the page URL you want to check (often your homepage or app shell).

2

Enable redirect following if needed

Keep "Follow Redirects" enabled so the analyzer reaches the final HTTPS/www/locale destination where the real CSP is returned.

3

Review the score card and findings

Start with findings to spot critical risks (unsafe-inline, wildcards, missing restrictions) and understand which directives are driving the score.

4

Inspect raw headers when debugging

Turn on "Show Raw Headers" to verify exact header names/values (useful if multiple CSP headers are present or a proxy/CDN modifies them).

5

Export a report for your security workflow

Download JSON for automation or PDF for security audits and engineering tickets.

Technical specs

Request model

This tool performs a URL header inspection and focuses on security header analysis, including CSP and report-only policies.

SettingBehaviorDefault
Follow RedirectsFollows the redirect chain to analyze the effective policy returned by the final URLEnabled
Max RedirectsRedirect cap to prevent loops10
TimeoutRequest timeout limit15000 ms
User-AgentIdentifies the request user agentEncode64Bot/1.0 (+https://encode64.com)
Private networksBlocks access to private network ranges for safetyDisabled (private networks not allowed)

CSP headers inspected

The analyzer checks for both enforcing and non-enforcing policies and surfaces them in a readable form.

HeaderMeaning
Content-Security-PolicyEnforced policy applied by the browser
Content-Security-Policy-Report-OnlyNon-blocking policy that reports violations (useful for rollout and tuning)
Sites may emit multiple CSP headers. Browsers apply combination/precedence rules that can be tricky—raw headers help confirm what's being sent.

What the analysis looks for

Findings are based on practical CSP hardening checks and common deployment mistakes.

AreaExamples of findings
Script policy strengthunsafe-inline / unsafe-eval usage, wildcard sources, missing nonce/hash strategy
Style policy strengthunsafe-inline styles, overly broad sources, missing migration path to nonces/hashes where feasible
Framing and clickjacking resistanceMissing or weak frame restrictions (often via frame-ancestors)
Legacy / deprecated patternsOld directives or patterns that should be modernized
Rollout readinessReport-Only presence and reporting endpoints visibility

Command line

Use these commands to inspect CSP headers quickly. They're useful for validating what the analyzer reports.

macOS / Linux

Fetch response headers (look for CSP)

curl -I https://example.com

Inspect Content-Security-Policy and Content-Security-Policy-Report-Only in the response headers.

Follow redirects while checking headers

curl -IL https://example.com

Ensures you see CSP headers from the final destination (HTTPS, www, app shell route).

Show CSP headers only (case-insensitive match)

curl -I https://example.com | grep -i "content-security-policy"

Quickly isolates CSP and report-only headers from the full header set.

Windows (PowerShell)

Inspect CSP headers

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-Report-Only']

Displays enforcing and report-only CSP headers if present.

Deploy new policies in Report-Only first, review violation reports, then tighten and enforce. CSP tuning is iterative for modern apps.

Use cases

Harden a site against XSS

Use CSP to reduce the impact of injection vulnerabilities by restricting where scripts/styles can load from and how inline code is handled.

  • Identify unsafe-inline/unsafe-eval and plan a migration to nonces/hashes
  • Restrict script-src/style-src sources to trusted origins
  • Add missing defensive directives (base-uri, object-src, frame-ancestors)

Roll out CSP safely with Report-Only

Introduce CSP gradually without breaking production by starting with Content-Security-Policy-Report-Only and iterating on violations.

  • Detect report-only policy presence
  • Understand what would be blocked before enforcing
  • Export a report for your rollout plan and tickets

Debug broken scripts, iframes, or third-party widgets

Overly strict CSP can block analytics, embeds, or API connections. Use the analyzer to see what the policy permits and where you may need explicit sources.

  • Confirm allowed script/img/connect/frame sources
  • Detect overbroad wildcards added as a quick fix
  • Replace broad allowances with targeted domains

Security review / compliance evidence

Generate a consistent report of current CSP posture for security reviews, client questionnaires, or internal compliance.

  • Download JSON for tracking changes over time
  • Download PDF for audit artifacts and sharing

❓ Frequently Asked Questions

❓What is CSP and what does it protect against?

Content Security Policy (CSP) is a browser-enforced security layer that restricts where resources can load from and how scripts/styles execute. It's primarily used to reduce the impact of cross-site scripting (XSS) and injection attacks.

❓What's the difference between CSP and CSP Report-Only?

Content-Security-Policy is enforced (it can block). Content-Security-Policy-Report-Only does not block; it reports violations so you can tune a policy before enforcing it.

❓Why is unsafe-inline considered dangerous?

unsafe-inline allows inline scripts/styles, which weakens CSP's ability to stop injected code. Safer approaches use nonces or hashes to allow only known inline blocks while still blocking unexpected injections.

❓Do I need nonces or hashes?

If your app uses inline scripts or styles, nonces/hashes are the modern way to keep CSP effective without breaking functionality. They allow specific inline blocks while preventing arbitrary injection.

❓Can a CDN or proxy change my CSP header?

Yes. Edge layers can add, merge, or override headers. If something looks inconsistent, enable raw headers and follow redirects to verify the final response headers.

❓Is CSP a replacement for fixing XSS bugs?

No. CSP is a defense-in-depth control. You still need proper output encoding, safe templating, and input validation. CSP reduces blast radius if something slips through.

❓Is it safe to paste URLs here?

The tool makes server-side requests to the provided URL and blocks private-network targets. Avoid putting secrets in URLs (like tokens in query strings) and prefer public URLs you trust.

Pro Tips

Best Practice

Start with Content-Security-Policy-Report-Only, collect violations, then tighten and enforce. CSP is iterative for real apps.

Security Tip

Replace unsafe-inline with a nonce or hash strategy. Keep policies explicit and minimal.

Security Tip

Add frame-ancestors to reduce clickjacking risk and avoid relying only on legacy headers.

Security Tip

Avoid broad wildcards as a quick fix. Prefer targeted domains for scripts/images/connect and review third-party needs.

CI Tip

Export a JSON report and track CSP changes in CI so you catch regressions when headers are modified by CDN/app updates.

Additional Resources

Content Security Policy (MDN)
Reference
Content-Security-Policy header (MDN)
Documentation
Content-Security-Policy-Report-Only (MDN)
Documentation
XSS guide (OWASP)
Documentation
CSP Cheat Sheet (OWASP)
Reference

Other Tools