CSP Evaluator

Review Content Security Policy rules before shipping them

Paste a Content-Security-Policy header value to inspect directives, catch risky sources like unsafe-inline or wildcards, and see simple hardening feedback in one place.

CSP input

Paste only the header value, not the Content-Security-Policy: prefix.

Risky

Score

0

Warnings

5

Info

0

Good

0

Key findings

Warnings

  • No CSP directives found. Paste a Content-Security-Policy value to evaluate it.
  • Missing default-src directive. Add a restrictive fallback policy.
  • Missing object-src directive. Consider object-src 'none'.
  • Missing base-uri directive. Consider base-uri 'self' or 'none'.
  • Missing frame-ancestors directive. Consider frame-ancestors 'none' or a trusted allowlist.

Parsed directives

Duplicate directives are highlighted because later ones can override earlier values.

No directives parsed yet.

What to check

  • Prefer default-src 'self' as a restrictive fallback.
  • Avoid unsafe-inline and unsafe-eval unless you truly need them.
  • Lock down object-src, base-uri, and frame-ancestors for stronger hardening.
  • Add report-uri or report-to if you want visibility into policy violations.

About CSP Evaluator

The CSP Evaluator is a free browser-based tool that parses a Content-Security-Policy header value, detects risky directive sources, and produces a security score with actionable hardening feedback — all without sending your policy to any server.

  • Parses every CSP directive and displays its source tokens at a glance.
  • Flags dangerous keywords like 'unsafe-inline', 'unsafe-eval', and wildcard sources (*).
  • Checks for missing directives such as object-src, base-uri, and frame-ancestors.
  • Detects duplicate directives that can silently override earlier values.
  • Calculates a 0–100 security score and labels your policy as Strong, Needs Review, or Risky.
  • Provides plain-English recommendations so you know exactly what to fix and why.

How to Evaluate a Content Security Policy Online

  1. 1

    Get your CSP header value

    Find the value in your server config, a browser DevTools response header, or a curl -I output. Copy everything after Content-Security-Policy: — do not include the header name itself.

  2. 2

    Paste the policy into the CSP Input box

    The evaluation runs automatically as you type. You can also click "Load sample" to see a realistic example policy with several common issues.

  3. 3

    Review the security score and Key Findings

    Warnings (red) indicate serious risks. Info (blue) notes things worth considering. Good signals (green) confirm best-practice directives are present.

  4. 4

    Inspect the Parsed Directives panel

    See each directive broken into individual source tokens. Duplicate directives are highlighted in amber — later ones override earlier values in the browser.

  5. 5

    Fix issues and re-evaluate

    Edit your policy directly in the input box and watch the score update live. Aim to resolve all warnings before shipping to production.

  6. 6

    Copy the cleaned directives

    Click "Copy parsed directives" to export the normalized, one-directive-per-line version of your policy for use in your server config or a PR description.

Tip: Start with default-src 'self' and explicitly allow only the origins your app actually needs. Each wildcard or unsafe keyword you remove improves your score and reduces your XSS attack surface.

Common Use Cases

Pre-deploy Security Review

  • • Evaluate your CSP before pushing a new header config to production.
  • • Catch accidental 'unsafe-inline' additions introduced during a dependency upgrade.
  • • Include the score in your deployment checklist or PR template.

Security Audits & Penetration Testing

  • • Quickly assess the CSP posture of an application under review.
  • • Identify exploitable weaknesses like missing object-src 'none' or permissive script sources.
  • • Generate a findings summary to include in a security report.

Learning & Understanding CSP

  • • Use the sample policy to explore how directives interact.
  • • Understand why 'unsafe-eval' and wildcard sources are risky.
  • • Experiment with different directive combinations and see their impact on the score.

Incremental Policy Hardening

  • • Start from a permissive policy and iteratively remove risky sources.
  • • Track score improvements as you lock down each directive.
  • • Use the "What to check" guide to prioritize which directives to address first.

Third-party Integration Review

  • • Verify that adding a new analytics or ad script doesn't require unsafe keywords.
  • • Evaluate whether third-party CDN sources are explicitly listed or covered by wildcards.
  • • Confirm that iframe embeds are covered by frame-src or frame-ancestors.

Compliance & Bug Bounty Programs

  • • Document your CSP security score for SOC 2, ISO 27001, or OWASP compliance evidence.
  • • Assess CSP weaknesses as part of a bug bounty submission.
  • • Confirm that report-uri or report-to is configured for violation monitoring.

Frequently Asked Questions

Is my CSP policy sent to a server?

No. All parsing and evaluation happens entirely in your browser using JavaScript. Your policy string is never uploaded, logged, or stored anywhere.

What is a Content Security Policy (CSP)?

A Content Security Policy is an HTTP response header that tells browsers which content sources are trusted for your page. It is one of the most effective defenses against Cross-Site Scripting (XSS) attacks because it prevents browsers from executing scripts from unauthorized origins.

Why is 'unsafe-inline' dangerous?

'unsafe-inline' allows inline <script> and <style> tags, which means an attacker who injects HTML into your page can execute arbitrary JavaScript. It effectively disables the main XSS protection that CSP provides.

What does the CSP security score mean?

The score (0–100) is a weighted measure of how well your policy limits attack surface. It rewards restrictive directives like object-src 'none' and penalizes risky ones like wildcard sources or 'unsafe-inline'. A score of 85 or above is labeled Strong; 65–84 is Needs Review; below 65 is Risky.

Should I include the Content-Security-Policy: header name when pasting?

No — paste only the header value. For example, paste default-src 'self'; script-src 'self' https://cdn.example.com, not Content-Security-Policy: default-src 'self'....

What are duplicate directives and why do they matter?

If a directive like script-src appears more than once in a policy, browsers use only the first occurrence and ignore later ones. This can cause unexpected behavior where you think a source is blocked, but it's actually allowed by an earlier definition.

What is report-uri and should I add it?

The report-uri (or the newer report-to) directive tells the browser where to send a JSON report when a CSP violation occurs. Adding it gives you visibility into attempted attacks and policy misconfigurations without blocking anything.

How is this different from Google's CSP Evaluator?

Google's CSP Evaluator sends your policy to their API for evaluation. This tool processes everything locally in your browser, so it is suitable for evaluating policies that contain internal hostnames, private CDN URLs, or other information you don't want to share with a third-party service.