ESC

CSP Directives

Generated Output

Configure directives to generate your CSP header...
Configure directives to generate your CSP header...
Configure directives to generate your CSP header...
Configure directives to generate your CSP header...
All processing happens in your browser. No data is sent to any server.

Usage Examples

Basic Restrictive Policy

A simple policy that only allows resources from your own domain, with inline styles and data URIs for images.

CDN-Friendly Policy

A policy that allows loading scripts and styles from popular CDNs like jsDelivr, cdnjs, and Google Fonts.

Strict Security Policy

A highly restrictive policy that blocks everything by default and only allows specific resource types from your domain.

Features

Visual Builder

Build your CSP header visually with checkboxes and dropdowns, no manual syntax needed

Server Configs

Get ready-to-use configuration snippets for Nginx, Apache, and meta tags

CSP Validation

Test your CSP for common security issues and best practice violations

Privacy First

All processing happens locally in your browser, no data sent to servers

How to Use?

1

Select Directives

Enable the CSP directives you need and choose sources for each one using checkboxes or custom domains.

2

Review Output

View your generated CSP as an HTTP header, meta tag, or server config snippet. Test it for issues.

3

Copy & Deploy

Copy the generated CSP and add it to your web server configuration or HTML document.

Frequently Asked Questions

Content Security Policy (CSP) is an HTTP response header that tells the browser which sources of content it should trust. Its primary defense is against XSS (Cross-Site Scripting) attacks — if an attacker injects a malicious script tag into your page, the browser will refuse to execute it if the source is not in your whitelist. CSP also protects against data injection attacks, clickjacking (with frame-ancestors), and mixed content issues.

default-src is the fallback for any resource type that does not have its own specific directive. If you have default-src 'self' but no script-src, scripts are restricted to same-origin by default. If you set script-src explicitly, it overrides default-src for scripts. Always set default-src as your baseline — it ensures resource types you forgot to configure have a restrictive default rather than no restriction at all.

unsafe-inline allows all inline scripts and styles, which defeats most of CSP's XSS protection. Nonces are a safer alternative: the server generates a random nonce (e.g. nonce-abc123) and adds it to the CSP header and to each trusted inline script tag. The browser only executes inline scripts that have a matching nonce. Since attackers cannot know the nonce (it changes per request), injected scripts cannot claim it.

report-uri tells the browser where to send JSON reports whenever a CSP violation occurs. Your server receives a POST request with details about the blocked resource, the violated directive, and the page URL. This is invaluable for auditing your CSP before enforcing it — use Content-Security-Policy-Report-Only mode first to see violations without blocking anything, then tighten the policy based on the reports.

Allowlist the exact origin rather than using wildcards. Instead of script-src *, use script-src 'self' https://cdn.jsdelivr.net. Each added origin is a potential attack vector if that CDN is compromised, so add only what you actually use. For Google Fonts, you need both style-src https://fonts.googleapis.com and font-src https://fonts.gstatic.com. This tool lets you add custom domain entries for each directive.

Yes, but with limitations. A meta tag (<meta http-equiv="Content-Security-Policy" content="...">) works in the HTML document's <head>. However, it cannot use frame-ancestors, report-uri, or sandbox directives — those only work as HTTP headers. Also, the meta tag only applies after the browser parses it, meaning resources declared before it in the document are not protected. HTTP headers are strongly preferred for full protection.

The validator flags these common issues: missing default-src (no fallback directive), use of unsafe-inline in script-src or style-src (weakens XSS protection significantly), use of unsafe-eval (allows dynamic code execution via eval()), and use of wildcard (*) origins (allows loading from any source). These are the most common CSP mistakes found in security audits.

No. Everything runs in your browser. Nothing is sent to a server or stored anywhere.

What Is Content Security Policy?

Content Security Policy (CSP) is an HTTP header that tells the browser which sources of content it should trust. Think of it as a whitelist: if a script, stylesheet, image, or font isn't from an approved source, the browser blocks it. This is your strongest defense against XSS attacks, because even if an attacker injects a malicious script tag into your page, the browser won't execute it if the source isn't whitelisted.

Why CSP Syntax Is Painful to Write by Hand

A real-world CSP header can easily be 500+ characters with dozens of directives, each with multiple sources. One misplaced semicolon breaks the whole thing, and there's no helpful error message - the browser just silently ignores the malformed parts. This tool gives you a visual interface: check boxes, dropdowns, and custom domain fields that generate valid CSP syntax automatically. You get output for HTTP headers, meta tags, Nginx, and Apache configs.

The Most Common CSP Mistakes

The biggest one is using unsafe-inline for scripts - it essentially turns off the XSS protection that CSP exists to provide. The second is using a wildcard (*) origin, which allows loading from any domain. The third is forgetting default-src, which means unspecified resource types have no restrictions. This tool has a built-in validator that flags all of these issues before you deploy.

Getting Started with CSP

Start with a report-only policy (Content-Security-Policy-Report-Only) to see what would break without actually blocking anything. Monitor the reports, fix the violations by adding legitimate sources, then switch to enforcement mode. This tool supports both modes and the presets give you common starting configurations for different security levels.

Privacy

Your CSP configuration never leaves your browser. No server calls, no storage, no tracking. The tool runs entirely in JavaScript.

Security and Privacy

Your data security is our priority

Local Processing

All processing happens in your browser

No Data Transfer

Your data is not sent to our servers

No Data Storage

No data is stored or shared

SSL Encryption

SSL encryption for secure connection

Also on MoreOnlineTools