CSP Builder & Validator — Content Security Policy Tool

How to CSP Builder & Validator Online

1. 1

   Paste your existing Content-Security-Policy header string into the raw input editor, or use the visual directive builder to configure policy rules interactively.

2. 2

   Configure resource directives (such as default-src, script-src, style-src, connect-src, img-src, and frame-ancestors) and assign authorized origins, nonces, or SHA-256 hashes.

3. 3

   Click "Analyze" or press ⌘↵ (Ctrl+Enter) to evaluate your policy against W3C Level 2 and Level 3 standards and receive an automated security grade from A (Strong) to F (Critical).

4. 4

   Inspect security warnings and vulnerabilities flagged by the analyzer, including permissive wildcard asterisks (*), unsafe-inline scripts, and missing fallback directives.

5. 5

   Click "Optimize CSP" to automatically deduplicate source origins, prune redundant directives, and convert legacy directives into modern strict alternatives.

6. 6

   Toggle "Report-Only" mode for non-blocking telemetry deployment, then copy your formatted policy for Nginx, Apache, Caddy, Cloudflare, Next.js middleware, or HTML meta tags.

CSP Builder & Validator Features

• ✓

  Interactive visual policy builder: toggle and configure 20+ W3C Level 2 and Level 3 CSP directives without manual syntax formatting.

• ✓

  Automated A-to-F security grading: instant scoring algorithm that evaluates attack surface exposure, fallback robustness, and directive specificity.

• ✓

  Vulnerability heuristic detection: automatically flags high-risk settings like wildcard (*) origins, script-src unsafe-inline, and unsafe-eval.

• ✓

  Cryptographic nonce and SHA hash support: seamlessly integrate nonces and SHA-256/SHA-384/SHA-512 hashes to safely eliminate unsafe-inline scripts.

• ✓

  One-click policy optimizer: strips duplicate origins, removes redundant protocol schemes, and collapses overlapping wildcard subdomains.

• ✓

  Production-ready architecture presets: pre-configured templates for Strict Zero-Trust, Modern Full-Stack SPAs, CDN-heavy assets, and WordPress setups.

• ✓

  Dual enforcement modes: toggle seamlessly between active blocking (Content-Security-Policy) and diagnostic staging (Content-Security-Policy-Report-Only).

• ✓

  Multi-platform server export snippets: generate copy-paste configurations formatted for Nginx (add_header), Apache (Header set), Caddy, Cloudflare, Next.js, and HTML <meta> tags.

• ✓

  Bidirectional parser and validator: parse raw CSP header strings into structured AST objects and regenerate clean, normalized policy strings.

• ✓

  Comprehensive keyboard shortcuts: analyze (⌘↵), copy header (⌘⇧C), clear editor (⌘⇧K), and cycle example presets (⌘⇧E) with zero friction.

• ✓

  JSON schema and AST inspector: export and import structured directive configurations for automated CI/CD pipeline policy audits.

• ✓

  100% client-side zero-retention security: all policy analysis and parsing runs locally in your browser with zero server telemetry or network logging.

Supported Formats & Dialects

The CSP Builder & Validator supports 6 syntax formats and dialects for accurate parsing and processing.

W3C CSP Level 3 Directives (strict-dynamic, report-to, navigate-to)

The W3C Content Security Policy Level 3 specification introduces powerful modern controls such as strict-dynamic (allowing trusted scripts with a nonce or hash to dynamically propagate trust to child scripts), report-to (integrating with the modern Reporting API), and navigate-to (restricting document destination URLs). Level 3 substantially streamlines script authorization for modern JavaScript frameworks and tag managers.

W3C CSP Level 2 Fetch Directives (default-src, script-src, connect-src, img-src, font-src)

Core fetch directives that regulate resource loading across origins. default-src acts as the fallback mechanism for unstated fetch directives. Dedicated directives like connect-src (controlling fetch, XHR, and WebSockets), img-src, font-src, and media-src enable strict least-privilege scoping across distinct application data pathways.

Document & Navigation Directives (base-uri, form-action, frame-ancestors, sandbox)

Directives that protect document-level browsing context integrity. frame-ancestors supersedes the legacy X-Frame-Options header to protect against Clickjacking; base-uri prevents malicious <base href> DOM hijacking attacks; and form-action controls permissible destinations for form submissions.

Cryptographic Nonces & SHA Hashes ('nonce-*', 'sha256-*', 'sha384-*', 'sha512-*')

Cryptographic source expressions that authorize specific inline script and stylesheet blocks without resorting to unsafe-inline. Nonces use per-response random Base64 tokens (<script nonce="...">), while SHA-256/384/512 hashes whitelist exact cryptographic digests of immutable inline code blocks.

Report-Only Mode & Violation Logging (Content-Security-Policy-Report-Only, report-uri)

Staging mode that instructs browsers to evaluate policy compliance and dispatch JSON violation reports to designated endpoints (via report-uri or report-to) without blocking asset execution. This enables teams to test strict policies against production traffic to catch undocumented third-party dependencies before full enforcement.

Web Server & Meta Tag Deployment Formats (Nginx, Apache, Caddy, Next.js, HTML <meta>)

Configuration formats for delivering CSP across various infrastructure layers. HTTP response headers delivered by web servers (Nginx, Apache, Caddy) or edge reverse proxies (Cloudflare, Next.js middleware) support all directives, whereas client-side HTML <meta http-equiv="Content-Security-Policy"> tags support fetch directives but omit frame-ancestors, report-uri, and sandbox.

Frequently Asked Questions

What are the key architectural improvements in W3C CSP Level 3 compared to Level 2?

W3C CSP Level 3 introduces several pivotal enhancements over Level 2: 1) The strict-dynamic source expression, which allows cryptographically trusted scripts (via nonce or hash) to load downstream child dependencies dynamically without needing exhaustive domain allowlists; 2) The report-to directive, which integrates with the modern W3C Reporting API (deprecating report-uri); 3) The navigate-to directive, which restricts the URLs to which a document can initiate navigation; 4) Enhanced worker-src scoping distinct from child-src/script-src; and 5) Granular hash expressions for inline event handlers and attributes via unsafe-hashes.

Why does script-src 'unsafe-inline' eliminate XSS protection, and how do nonces or hashes resolve this?

When 'unsafe-inline' is enabled in script-src, the browser cannot distinguish between legitimate inline application scripts written by your team and malicious script payloads injected by an attacker via reflected, stored, or DOM-based XSS vulnerabilities. To eliminate this risk while maintaining necessary inline execution, modern CSP utilizes either cryptographic nonces ('nonce-<random-base64>')—unique, unguessable tokens generated per HTTP request and added as attributes to valid <script> tags—or cryptographic hashes ('sha256-<hash>') that match the exact SHA-256 digest of static inline script blocks.

How does 'strict-dynamic' streamline third-party script loading (like Google Tag Manager or Stripe.js)?

In traditional CSP Level 2, loading a complex third-party library like Google Tag Manager required allowlisting every single CDN domain, sub-resource, and tracker that GTM might inject. If a third party added a new analytics host, the application broke. CSP Level 3 'strict-dynamic' solves this by establishing trust propagation: any root script loaded with a valid cryptographic nonce or hash is granted permission to create dynamic <script> elements and load further scripts at runtime, completely eliminating fragile host allowlists.

Why is 'frame-ancestors' superior to the legacy 'X-Frame-Options' response header?

The legacy X-Frame-Options header only supports crude binary directives: DENY (disallow all embedding) or SAMEORIGIN (allow embedding only on the same origin). In contrast, W3C CSP frame-ancestors supports granular origin allowlisting (e.g., frame-ancestors 'self' https://trusted-partner.com https://*.example.org;), permits multiple authorized parent origins, and supports wildcard subdomains. Furthermore, W3C specifications dictate that modern browsers ignore X-Frame-Options whenever a CSP containing frame-ancestors is present.

How should development teams safely deploy strict CSP using Content-Security-Policy-Report-Only?

Deploying a strict CSP directly in enforcement mode on an active production website risks breaking vital third-party analytics, payment widgets, or marketing tags. The best-practice rollout strategy begins by serving the policy via the Content-Security-Policy-Report-Only header alongside a report-uri or report-to endpoint. In this mode, browsers execute all resources normally while transmitting structured JSON violation payloads to your reporting backend. Once telemetry confirms zero false-positive violations across normal user traffic, transition the header to Content-Security-Policy for active enforcement.

What is the fallback precedence between 'default-src' and specific fetch directives?

The default-src directive acts as a universal fallback for all fetch directives that are not explicitly defined in the policy (including script-src, style-src, img-src, connect-src, font-src, media-src, object-src, and worker-src). However, non-fetch directives—such as base-uri, form-action, and frame-ancestors—do NOT inherit from default-src and must always be declared individually. If a specific fetch directive is declared (e.g., img-src 'self'), it completely overrides default-src for that resource type rather than merging with it.

How do you implement dynamic cryptographic CSP nonces in Next.js App Router middleware?

In Next.js App Router, dynamic nonces are generated on every incoming request inside middleware.ts using crypto.randomUUID() converted to Base64. The middleware injects the generated nonce into the script-src directive (e.g., script-src 'self' 'nonce-${nonce}' 'strict-dynamic'), sets the Content-Security-Policy header on the outgoing response, and forwards the nonce to Server Components via a custom request header (such as x-nonce). Next.js Server Components and RootLayout then read headers().get('x-nonce') and pass it to inline <Script> components.

Which CSP directives are ignored by browsers when specified inside an HTML <meta> tag?

When CSP is declared via <meta http-equiv="Content-Security-Policy" content="..."> inside an HTML document, the W3C specification explicitly forbids and ignores three critical security directives: 1) frame-ancestors (clickjacking prevention must be evaluated before the document HTML is parsed); 2) report-uri / report-to (violation reporting is restricted to HTTP headers); and 3) sandbox (sandboxing alters document rendering flags before parsing). For complete security enforcement, always deliver CSP as an authentic HTTP response header from your web server or edge proxy.

How do 'object-src none' and 'base-uri self' protect against Flash, plugin, and DOM hijacking attacks?

Setting object-src 'none' blocks legacy browser plugins, Java applets, and Flash objects (<object>, <embed>, <applet>), completely closing a classic vector for sandbox escapes and memory corruption exploits. Setting base-uri 'self' (or 'none') restricts the <base href="..."> HTML tag; without this directive, an attacker who successfully injects an unclosed HTML tag or partial markup can redirect all relative script, image, and style URLs across the entire page to a malicious attacker-controlled domain.

How does this CSP Builder guarantee privacy and security during policy evaluation?

Our CSP Builder and Validator executes 100% client-side inside your browser sandbox using pure TypeScript AST parsing and validation algorithms. No Content Security Policy strings, domain names, server tokens, internal hostnames, or reporting endpoints are ever transmitted to our servers or stored in remote databases. Your infrastructure security policies remain strictly private on your device.

Related Developer Tools

• PWA Manifest & Service Worker AuditValidate manifest.json, inspect service worker config, and flag installability issues.
• HTTP Headers AnalyzerAnalyze HTTP response headers for security, caching, and compliance issues.
• Hash GeneratorGenerate and verify cryptographic hashes with multiple algorithms.
• HTML Entities Encoder/DecoderEncode and decode HTML entities with named, numeric, and hex modes.
• JWT DecoderDecode, inspect, and validate JWT tokens with claim and signature analysis.
• Password GeneratorGenerate secure passwords, passphrases, and PINs with real-time strength analysis.
• SSL/TLS Certificate DecoderDecode PEM & X.509 certificates offline or inspect live SSL/TLS certificate chains with expiration countdowns and health checks.
• Prompt Injection & Secret ScannerScan prompts, code, and text for prompt injection patterns, secret leaks, unsafe instructions, and PII exposure.
• Meta Tag GeneratorGenerate SEO meta tags, Open Graph, Twitter Cards, and JSON-LD structured data.