SEOlust logo SEOlust
Security & Privacy

CSP Analyzer (Content-Security-Policy Evaluator)

Paste a Content-Security-Policy and get a graded report — flags unsafe-inline, unsafe-eval, wildcards, and missing object-src, base-uri, and frame-ancestors. Runs in your browser. Free.

All tools
You can paste the raw policy, or the full header line (Content-Security-Policy: …).
–
– / 100 security score

Findings

    Directives

    💡 How to use

    • Paste your CSP to get a graded report of weaknesses and missing protections.
    • Findings are ranked: high (fix now), medium, low, info, and good.
    • Everything is analyzed in your browser — nothing is sent to a server.

    Free CSP Analyzer (Content-Security-Policy Evaluator)

    Paste a Content-Security-Policy and get an instant security grade with ranked findings. The analyzer flags risky sources like 'unsafe-inline', 'unsafe-eval', and wildcards, and highlights missing protections such as object-src, base-uri, and frame-ancestors. Runs entirely in your browser. Free, no sign-up.

    What is a Content Security Policy?

    A Content Security Policy (CSP) is an HTTP header that tells the browser which sources of scripts, styles, images, and other resources are allowed to load on your page. A well-configured CSP is one of the strongest defenses against cross-site scripting (XSS) and data-injection attacks, because it stops the browser from running untrusted code even if an attacker manages to inject it. A weak or misconfigured CSP, however, can give a false sense of security.

    How to use the CSP analyzer

    It is instant:

    • Paste your policy — either the raw value or the full Content-Security-Policy header line.
    • See an overall grade and security score.
    • Read the ranked findings, from high-risk issues to good practices you already follow.
    • Review the parsed directive breakdown to confirm the browser reads it the way you expect.

    The most common CSP weaknesses

    The analyzer checks for the issues that most often undermine a policy:

    • 'unsafe-inline' in script-src — lets inline scripts run, the single biggest XSS gap.
    • 'unsafe-eval' — enables eval() and similar dynamic code execution.
    • Wildcards (*) or bare schemes (https:) — allow scripts or resources from any host.
    • Missing object-src 'none' — plugins and embeds can bypass your script rules.
    • Missing base-uri — an injected <base> tag can hijack relative URLs.
    • Missing frame-ancestors — the page can be framed for clickjacking.

    Why nonces and hashes matter

    The modern way to allow specific inline scripts safely is with a nonce (a random token added to each allowed script and to the CSP) or a hash of the script's contents. When a nonce or hash is present, browsers ignore 'unsafe-inline', so you get the convenience of inline scripts without the risk. If the analyzer sees nonces or hashes in your script-src, it credits that as a strong practice — and downgrades the severity of any leftover 'unsafe-inline'.

    Directives every strong policy should set

    Beyond restricting scripts, a robust CSP locks down a few often-forgotten directives. Set object-src 'none' to disable legacy plugins, base-uri 'none' or 'self' to prevent base-tag injection, and frame-ancestors 'none' or 'self' to stop clickjacking (this replaces the old X-Frame-Options header). Adding form-action 'self' keeps forms from submitting to attacker-controlled endpoints, and a report-to or report-uri directive surfaces violations so you can catch problems in the wild.

    Pro tip

    Roll out CSP gradually: start with Content-Security-Policy-Report-Only so violations are reported but nothing is blocked, review the reports, then switch to enforcing mode once the policy is clean. Aim for default-src 'none' plus explicit allowlists and nonces for scripts. To build a policy from scratch, use our CSP Header Generator, and check your other headers with the Security Headers Checker.

    FAQ

    Is this CSP analyzer free and private?
    Yes. It is free and evaluates your policy entirely in your browser, so nothing you paste is uploaded or stored.
    How is the security score calculated?
    The analyzer starts at 100 and deducts points for each weakness by severity — high issues cost the most, then medium and low — producing a letter grade from A to F. Good practices are highlighted but do not add points.
    Why is 'unsafe-inline' considered dangerous?
    It allows any inline script to execute, which is exactly what a cross-site scripting attacker needs. If an attacker injects a script tag, 'unsafe-inline' lets it run. Use nonces or hashes instead.
    What should object-src, base-uri, and frame-ancestors be set to?
    A strong default is object-src 'none', base-uri 'none' or 'self', and frame-ancestors 'none' or 'self'. These close common bypass, injection, and clickjacking gaps that script rules alone do not cover.
    Does a CSP replace X-Frame-Options?
    Largely, yes. The frame-ancestors directive is the modern replacement for X-Frame-Options and is respected by current browsers. Keeping X-Frame-Options too can help very old browsers.
    What is the difference between enforce and report-only mode?
    Content-Security-Policy enforces the rules and blocks violations. Content-Security-Policy-Report-Only only reports violations without blocking, which is ideal for testing a new policy before enforcing it. This tool analyzes both.
    How do I build or fix my CSP?
    Use the findings here as a checklist, then generate or edit the policy with a CSP generator. Start restrictive with default-src 'none', allow only what you need, and use nonces or hashes for inline scripts.

    Related tools

    Pro tip: pair this tool with Robots.txt Exposure Checker and Cookie Security Checker for a faster SEO workflow.