CSP Generator
Build, audit, and export hardened Content Security Policy Level 3 headers. Eliminate Cross-Site Scripting (XSS), clickjacking, and data exfiltration with instant security scoring and multi-server configs.
Content Security Policy Builder
Your Content Security Policy enforces modern defense-in-depth protections against XSS, data exfiltration, and clickjacking.
💡 Test thoroughly in report-only mode ("Content-Security-Policy-Report-Only") before blocking production traffic.Configured CSP Directives
Click common tokens or type custom domainsFallback policy for fetch directives that are not explicitly defined.
Defines valid sources for JavaScript execution and web worker scripts.
Defines valid sources for stylesheets and inline style attributes.
Defines valid sources for images, favicons, and graphic assets.
Defines valid sources for web fonts loaded via @font-face.
Restricts URLs loaded using fetch(), XMLHttpRequest, WebSocket, and EventSource.
Defines valid sources for <audio> and <video> media elements.
Restricts sources for legacy plugins like Flash, Java, or Applets (<object>, <embed>).
Defines valid sources for nested browsing contexts loaded in <iframe> elements.
Specifies valid parents that may embed a page in <iframe>, <frame>, or <object> (Clickjacking protection).
Restricts the URLs which can be used as the target of form submissions.
Restricts the URLs that can be used in a document's <base> element.
Instructs user agents to treat all of an application's insecure URLs (HTTP) as though they have been replaced with HTTPS.
Prevents loading any mixed content over insecure HTTP connections.
In-Browser Content Security Policy Level 3 Generation and Security Auditing
The CSP Generator builds, audits, and formats Content Security Policy (CSP) Level 3 headers directly within your web browser. By constructing precise resource-loading rules and evaluating policies against real-world security heuristics in local memory, developers can protect web applications against Cross-Site Scripting (XSS), clickjacking, and unauthorized data exfiltration without sending server configurations to external endpoints.
Content Security Policy is an essential defense-in-depth standard defined by the W3C. It restricts which external origins and internal mechanisms can load and execute scripts (script-src), styles (style-src), images (img-src), network requests (connect-src), frames (frame-src), and plugin objects (object-src). Declaring strict document restrictions like frame-ancestors and base-uri prevents framing attacks and base tag hijacking.
This utility provides curated production presets for Single Page Applications, strict nonce-based workflows, static blogs, and Google Analytics integrations, alongside an automated security health score (0 to 100) that flags risky antipatterns like 'unsafe-inline' and wildcard origins, exporting ready-to-use configs for HTTP response headers, HTML meta tags, Nginx, and Apache.
Core Tool Capabilities
- W3C CSP Level 3 Directive Modeling: Configures comprehensive origin controls across fetch directives, document embedding rules, and navigation restrictions to establish a hardened defense perimeter.
- Real-Time XSS and Antipattern Auditing: Evaluates active policy rules against known security antipatterns, automatically deducting score points for dangerous wildcards or missing object-src restrictions.
- Curated Production Presets: Applies pre-configured baseline templates tailored for modern Single Page Applications, strict nonce-based setups, static documentation blogs, or analytics-enabled storefronts.
- Multi-Target Server Exports: Generates formatted configuration snippets ready for deployment as standard HTTP response headers, HTML meta tags, Nginx add_header directives, or Apache .htaccess rules.
- Interactive Source Token Configurator: Quickly toggle common source keywords ('self', 'none', 'strict-dynamic', https:, data:) or add custom API domains and cryptographic nonces with instant recalculation.
Local Browser Privacy
Your files are processed locally on your device. Files are not uploaded, transmitted, or stored on remote servers.
Once the page has loaded, you can disconnect your network connection and continue using this tool offline.
Target Use Cases
- • Single Page Application Security Hardening
- • Clickjacking and Framing Defense
- • Static Site and Blog Policy Generation
- • Mixed Content and Protocol Migration
Technical Specifications & Platform Limits
Official web application security standard.
Granular origin, script execution, and framing restrictions.
Universal deployment formats for web servers and CDNs.
Zero external network requests or server logging.
Step-by-Step Workflow
Select a Production Preset
Choose a baseline template matching your application stack, such as Modern Strict SPA or Static Blog.
Configure Directives and Domains
Toggle individual directives, add allowed external API or CDN domains, and adjust script execution rules.
Audit Policy Health Score
Review the automated security evaluation for any warnings regarding 'unsafe-inline' or missing base-uri restrictions.
Export Server Configuration
Select your preferred deployment format (HTTP Header, HTML Meta, Nginx, or Apache) and copy the policy to your clipboard.
Practical Real-World Use Cases
Single Page Application Security Hardening
Frontend developers building React, Vue, or Svelte applications to restrict script execution and prevent unauthorized data exfiltration.
Clickjacking and Framing Defense
Web application security engineers configuring frame-ancestors 'none' to prevent malicious sites from embedding pages in hidden iframes.
Static Site and Blog Policy Generation
Content creators and Jamstack engineers deploying hardened policies on Astro or Next.js blogs while allowing web fonts and assets.
Mixed Content and Protocol Migration
DevOps teams enforcing upgrade-insecure-requests to ensure legacy HTTP links are automatically loaded over encrypted HTTPS connections.
Frequently Asked Questions
- What is the difference between default-src and specific directives like script-src?
- The default-src directive serves as the fallback policy for fetch directives that are not explicitly declared. However, directives like base-uri, frame-ancestors, and form-action do not fall back to default-src and must be declared individually.
- Why is object-src 'none' strongly recommended?
- Setting object-src to 'none' prevents the browser from loading legacy browser plugins such as Flash, Java applets, or ActiveX controls via object and embed elements, eliminating an entire class of plugin execution vulnerabilities.
- Can I enforce frame-ancestors using an HTML meta tag?
- No. The frame-ancestors directive is ignored by browsers when specified inside an HTML meta tag. It must be delivered as a standard HTTP response header from your web server or CDN.
- What risks are introduced by adding 'unsafe-inline' to script-src?
- Allowing 'unsafe-inline' permits the execution of inline script tags and inline event handlers, disabling CSP's primary defense against Cross-Site Scripting (XSS). Using cryptographic nonces or hashes is the recommended alternative.
- How does the policy health score evaluate security?
- The health score evaluates whether dangerous keywords are present, whether vital directives like object-src and base-uri are defined, and whether wildcard origins are restricted to trusted hostnames.
Share this tool
Help others discover this utility. No login or registration required.
Master this tool with Guides & Articles
Learn the workflows, common mistakes, and advanced techniques behind CSP Generator - Build & Audit Content Security Policy Headers with our deep-dive educational content.