W3C CSP Level 3 Security Utility

Content Security Policy (CSP) Analyzer

Validate your website's Content-Security-Policy against W3C CSP Level 3 specifications. Inspect directive fallbacks, detect dangerous 'unsafe-inline' execution, verify cryptographic nonces, and score injection resistance.

W3C CSP Level 3Fallback Hierarchy Resolution'strict-dynamic' & NoncesOffline Paste & Remote ModesSSRF-Protected
W3C CSP Level 3 • Deterministic
Header Type:
Separate directives with semicolons (;)0 / 100,000 characters
Load Sample:
W3C Standard Defense

What is Content Security Policy (CSP)?

Content Security Policy (CSP) is an HTTP response header that provides a declarative defense-in-depth security layer against Cross-Site Scripting (XSS), clickjacking, code injection, and data exfiltration. By instructing modern browsers which origins, scripts, stylesheets, and embedded frames are authorized to run, CSP drastically limits the harm an attacker can inflict even if an application suffers from an input sanitization failure.

Enforcing Mode

Content-Security-Policy: ...

Instructs the browser to strictly block any resources or inline scripts that violate your rules. Violations trigger browser console errors and optional reports to your monitoring server.

Report-Only Mode

Content-Security-Policy-Report-Only: ...

Permits all scripts and resources to execute normally while dispatching violation reports in the background. Used in staging to benchmark third-party dependencies before full enforcement.

Deterministic Inheritance

Understanding the CSP Fallback Hierarchy

A common misconception in CSP engineering is that all directives inherit from default-src. Under W3C CSP Level 3, fetch directives fall back to default-src when omitted, but critical boundary directives such as base-uri, form-action, and frame-ancestors never inherit from default-src.

DirectiveFallback RuleSecurity Scope
script-srcInherits default-srcRestricts sources for JavaScript execution. Inherits from default-src if absent.
style-srcInherits default-srcRestricts stylesheets and style attributes. Inherits from default-src if absent.
img-srcInherits default-srcControls image loading origins. Inherits from default-src if absent.
connect-srcInherits default-srcRestricts XHR, fetch(), WebSocket, and EventSource connections. Inherits from default-src.
object-srcInherits default-srcRestricts <object>, <embed>, and <applet> plugins. Highly recommended to set to 'none'.
base-uriNever inheritsRestricts URLs allowed in <base> tags. MUST be explicitly configured; never inherits.
form-actionNever inheritsRestricts targets for form submissions (<form action>). MUST be explicitly configured.
frame-ancestorsNever inheritsControls which sites can embed this page in <iframe>. Never inherits from default-src.
Next-Gen Security Model

Modern CSP: Nonces & 'strict-dynamic'

Traditional CSP policies relied on host allowlists (e.g. script-src 'self' cdn.example.com). Empirical security research demonstrated that over 90% of host allowlists are bypassable via open redirects, CDN JSONP endpoints, or Angular library vulnerabilities. CSP Level 3 introduces nonce-based policies with 'strict-dynamic'.

Recommended Modern Strict CSP Architecture
default-src 'none'; script-src 'strict-dynamic' 'nonce-RANDOM_BASE64' 'unsafe-inline' https:; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none';

Why 'unsafe-inline' is included: In CSP Level 3 browsers, presence of a nonce or hash causes the browser to automatically ignore 'unsafe-inline'. It is retained solely as a backward-compatibility fallback for older browsers that lack Level 3 support.

Configuration Vulnerabilities

Common CSP Anti-Patterns & Bypasses

A poorly crafted Content Security Policy provides false reassurance while failing to prevent XSS exploits. Here are six of the most frequent misconfigurations audited by our analyzer:

Omitted 'object-src' Directive

CSP_OBJECT_SRC_MISSING

Leaving out object-src allows malicious Flash, Java applets, or PDF plugins to execute in older or legacy browser contexts, bypassing script-src restrictions.

Remediation: Explicitly declare object-src 'none' in your policy unless plugin execution is mandatory.

Missing 'base-uri' Restriction

CSP_BASE_URI_MISSING

base-uri does NOT inherit from default-src. If omitted, attackers can inject a <base href="https://attacker.com"> tag to hijack relative script imports.

Remediation: Explicitly set base-uri 'self' or base-uri 'none' to prevent base tag manipulation.

Permissive Wildcard Host Sources

CSP_WILDCARD_SOURCE

Using wildcard origins like * or https:* grants unrestricted script loading, permitting any external domain to serve executable JavaScript.

Remediation: Replace wildcards with cryptographic nonces, SHA-256 hashes, or specific trusted origins.

Unquoted Keyword Literals

CSP_UNQUOTED_KEYWORD

Writing self, none, or unsafe-inline without single quotes causes browsers to treat them as hostname endpoints (e.g., http://self) rather than special directives.

Remediation: Always wrap keywords in single quotes: 'self', 'none', 'unsafe-inline', 'strict-dynamic'.

Missing 'frame-ancestors' (Clickjacking)

CSP_FRAME_ANCESTORS_MISSING

frame-ancestors does NOT fall back to default-src. Without it, third-party sites can embed your application in an iframe for UI redressing attacks.

Remediation: Declare frame-ancestors 'self' or frame-ancestors 'none' to supersede legacy X-Frame-Options.

Active 'unsafe-eval' in Production

CSP_UNSAFE_EVAL_USAGE

Enabling 'unsafe-eval' permits window.eval(), Function(), and setTimeout(string), dramatically increasing the blast radius of injection flaws.

Remediation: Refactor legacy templating or math parsing libraries to use precompiled templates and JSON parsers.
Production Roadmap

How to Roll Out a Strict CSP Without Breaking Production

Deploying an aggressive CSP overnight will inevitably break third-party analytics, chat widgets, or inline tag managers. Follow this staged production rollout protocol:

1

Phase 1: Asset & Script Inventory

Catalog all external script sources, CDNs, analytics providers, and third-party widgets across all application routes.

2

Phase 2: Deploy Report-Only Header

Publish Content-Security-Policy-Report-Only with a report-uri or report-to endpoint. Collect telemetry across real browser traffic for 7 to 14 days.

3

Phase 3: Refactor Inline Scripts to Nonces

Replace raw inline <script> tags and onclick handlers with server-generated cryptographic nonces or external modular JS files.

4

Phase 4: Enforce Strict CSP

Switch the response header name to Content-Security-Policy. Block unauthorized resources while maintaining telemetry reporting.

5

Phase 5: Automated CI/CD Regression Verification

Integrate SiteSecura's CSP analyzer into your CI pipeline to prevent new pull requests from introducing permissive wildcards or unsafe keywords.

Frequently Asked Questions

Detailed answers covering W3C specifications, bypass scenarios, report endpoints, and nonce implementation.

Content Security Policy (CSP) is an HTTP response header that allows site operators to restrict the origins and execution contexts from which browsers may load and execute resources such as JavaScript, CSS, images, frames, fonts, and media. Governed by W3C specifications (currently CSP Level 3), it serves as a foundational defense-in-depth security layer designed primarily to defeat Cross-Site Scripting (XSS) and data injection attacks.
Full-Stack Security Assessment

Complete Perimeter Website Security Audit

Scan your website across SSL/TLS certificates, DNSSEC, email security (SPF, DKIM, DMARC), security headers, and open ports in under 60 seconds.