Documentation
How to use this tool, practical use cases, and technical notes.
The CSP Generator is designed to produce a deployable Content-Security-Policy header in under five minutes. Here is a complete walkthrough of every control in the tool, with guidance on making the right choices for your application.
Step 1 — Choose a Policy Preset
The tool offers four starting profiles accessible via tabs at the top of the workspace. Select the one that best matches your goal:
Preset | When to Use | Default Posture |
|---|---|---|
Strict | New application; security-first; willing to configure inline script nonces | Blocks nearly everything not explicitly allowed; no |
Balanced | Established application with some third-party dependencies | Allows |
Report-Only | Production site where you can't afford breakage; want to observe before enforcing | Same directives but delivered via |
Legacy / Dev | Legacy codebase with inline scripts and eval; development environment | Permissive; not suitable for production |
Recommended starting workflow: Begin with Report-Only using a Strict or Balanced base, deploy to production, monitor violations for 1–2 weeks, tighten the policy based on real traffic, then switch to enforcing mode.
Step 2 — Configure Each Directive
The tool exposes eight directives, each with a dropdown of pre-categorized sources and a custom source input. Work through each directive relevant to your application:
default-src
The fallback directive. Any fetch directive not explicitly set in your policy inherits from default-src. Setting it to 'self' means all unspecified resource types are restricted to same-origin by default.
Source Value | Effect | Risk Level |
|---|---|---|
| Same origin only | ✅ Low |
| Any HTTPS URL | ⚠️ Medium |
| Block everything (explicit allowlist only) | ✅ Lowest |
| Any URL | ❌ High — defeats CSP |
Best practice: Set default-src 'self' and then explicitly define each other directive. This ensures that new resource types are blocked by default rather than open.
script-src
Controls which JavaScript sources are allowed to execute. This is the most security-critical directive — XSS attacks almost always involve executing unauthorized scripts.
Source Value | Effect | Recommended? |
|---|---|---|
| Same-origin scripts only | ✅ Yes |
| Scripts with matching nonce attribute only | ✅ Best practice |
| Scripts matching specific hash | ✅ For static inline scripts |
| Trusts scripts loaded by nonce/hash-trusted scripts | ✅ CSP Level 3 |
| All inline | ❌ Defeats XSS protection |
|
| ❌ Dangerous; avoid |
| WebAssembly compilation only | ⚠️ Use if WASM required |
CDN URLs (jsDelivr, unpkg) | Scripts from named CDNs | ⚠️ Trust the CDN's security |
Tool tip: The tool marks 'unsafe-inline', 'unsafe-eval', and http: sources with a ⚠️ warning badge to signal elevated risk.
style-src
Controls stylesheet sources. Less dangerous than script-src but still a vector for CSS injection attacks that can exfiltrate data or manipulate UI.
Source Value | Notes |
|---|---|
| Recommended baseline |
| Often needed for frameworks (React, Vue inline styles); use with caution |
| Allows style attributes matching a specific hash (CSP Level 3) |
| Required if using Google Fonts |
img-src
Controls where images and favicons can load from. The tool defaults to 'self' data: https: — a practical default that allows inline Base64 images (used by many UI frameworks) and any HTTPS-hosted image.
Source Value | Common Need |
|---|---|
| Local images |
| Base64 embedded images (common in frameworks, email clients) |
| Any HTTPS image host (analytics pixels, CDN images) |
| Canvas-generated or file-reader images |
Specific host |
|
connect-src
Controls targets for fetch(), XMLHttpRequest, WebSocket, and EventSource. Critical for API-heavy applications and real-time features.
Source Value | Typical Use Case |
|---|---|
| API calls to own domain |
| Calls to a specific external API |
| WebSocket connections |
| Any HTTPS API endpoint (broad; acceptable if no sensitive endpoints) |
| Google Analytics data collection |
frame-ancestors
Replaces the older X-Frame-Options header. Defines which origins are allowed to embed this page in a <frame>, <iframe>, <object>, or <embed>.
Value | Effect | Use Case |
|---|---|---|
| Nobody can iframe this page | ✅ Strongest; use for login pages, dashboards |
| Only same origin can iframe | Most common |
| Specific partner origin only | Controlled embedding |
| Anyone can iframe | ❌ Enables clickjacking |
Note: frame-ancestors cannot be set via <meta> tag — it only works as an HTTP response header. This tool outputs it correctly in the header format but omits it from the meta tag output.
base-uri
Restricts what URLs can appear in a <base> element. Base tag injection allows attackers to rewrite all relative URLs on the page to point to a malicious server.
Value | Recommendation |
|---|---|
| ✅ Recommended — restrict to own origin |
| ✅ If you don't use |
Omitted | ❌ Falls through to |
form-action
Controls where HTML forms can submit data. Without this directive, a stored XSS that injects a <form action="https://evil.com"> can silently exfiltrate user input.
Value | Effect |
|---|---|
| Forms can only submit to the same origin |
| Forms submit to a specific API endpoint |
| No form submissions allowed (rare; API-only apps) |
Step 3 — Add Custom Sources
For any directive, click "Custom source" and type a hostname, URL pattern, or scheme. The tool appends it to the selected sources list and immediately updates the live output. Valid formats include:
Format | Example | Matches |
|---|---|---|
Exact host |
| That exact host on HTTPS |
Host with wildcard |
| Any subdomain of example.com |
Scheme only |
| Any URL on HTTPS |
Path-specific |
| That path only |
Step 4 — Toggle Report-Only Mode
The Report-Only header toggle switches the output between:
Content-Security-Policy:— enforcing mode (browsers block violations)Content-Security-Policy-Report-Only:— monitoring mode (browsers log violations, do not block)
Both can be deployed simultaneously in production — Report-Only for testing a new stricter policy while keeping the enforcing policy unchanged.
Step 5 — Copy Your Output
The tool generates three output formats simultaneously. Choose based on your deployment context:
Output Format | When to Use |
|---|---|
CSP policy string | Paste into nginx |
HTTP response header | Full header line ready to paste into server config files verbatim |
HTML | When you cannot modify HTTP headers — static site generators, CDNs without header control, email HTML |
Step 6 — Apply Deployment Tips
The tool surfaces three critical reminders on every policy generation:
Start with Report-Only and monitor violations before switching to enforcing mode
Use nonces instead of
'unsafe-inline'for scripts — nonces prevent inline script injection even if an attacker can inject HTMLSet
frame-ancestors 'none'unless your application legitimately needs to be embedded in iframes
The CSP Generator is designed to produce a deployable Content-Security-Policy header in under five minutes. Here is a complete walkthrough of every control in the tool, with guidance on making the right choices for your application.
Step 1 — Choose a Policy Preset
The tool offers four starting profiles accessible via tabs at the top of the workspace. Select the one that best matches your goal:
Preset | When to Use | Default Posture |
|---|---|---|
Strict | New application; security-first; willing to configure inline script nonces | Blocks nearly everything not explicitly allowed; no |
Balanced | Established application with some third-party dependencies | Allows |
Report-Only | Production site where you can't afford breakage; want to observe before enforcing | Same directives but delivered via |
Legacy / Dev | Legacy codebase with inline scripts and eval; development environment | Permissive; not suitable for production |
Recommended starting workflow: Begin with Report-Only using a Strict or Balanced base, deploy to production, monitor violations for 1–2 weeks, tighten the policy based on real traffic, then switch to enforcing mode.
Step 2 — Configure Each Directive
The tool exposes eight directives, each with a dropdown of pre-categorized sources and a custom source input. Work through each directive relevant to your application:
default-src
The fallback directive. Any fetch directive not explicitly set in your policy inherits from default-src. Setting it to 'self' means all unspecified resource types are restricted to same-origin by default.
Source Value | Effect | Risk Level |
|---|---|---|
| Same origin only | ✅ Low |
| Any HTTPS URL | ⚠️ Medium |
| Block everything (explicit allowlist only) | ✅ Lowest |
| Any URL | ❌ High — defeats CSP |
Best practice: Set default-src 'self' and then explicitly define each other directive. This ensures that new resource types are blocked by default rather than open.
script-src
Controls which JavaScript sources are allowed to execute. This is the most security-critical directive — XSS attacks almost always involve executing unauthorized scripts.
Source Value | Effect | Recommended? |
|---|---|---|
| Same-origin scripts only | ✅ Yes |
| Scripts with matching nonce attribute only | ✅ Best practice |
| Scripts matching specific hash | ✅ For static inline scripts |
| Trusts scripts loaded by nonce/hash-trusted scripts | ✅ CSP Level 3 |
| All inline | ❌ Defeats XSS protection |
|
| ❌ Dangerous; avoid |
| WebAssembly compilation only | ⚠️ Use if WASM required |
CDN URLs (jsDelivr, unpkg) | Scripts from named CDNs | ⚠️ Trust the CDN's security |
Tool tip: The tool marks 'unsafe-inline', 'unsafe-eval', and http: sources with a ⚠️ warning badge to signal elevated risk.
style-src
Controls stylesheet sources. Less dangerous than script-src but still a vector for CSS injection attacks that can exfiltrate data or manipulate UI.
Source Value | Notes |
|---|---|
| Recommended baseline |
| Often needed for frameworks (React, Vue inline styles); use with caution |
| Allows style attributes matching a specific hash (CSP Level 3) |
| Required if using Google Fonts |
img-src
Controls where images and favicons can load from. The tool defaults to 'self' data: https: — a practical default that allows inline Base64 images (used by many UI frameworks) and any HTTPS-hosted image.
Source Value | Common Need |
|---|---|
| Local images |
| Base64 embedded images (common in frameworks, email clients) |
| Any HTTPS image host (analytics pixels, CDN images) |
| Canvas-generated or file-reader images |
Specific host |
|
connect-src
Controls targets for fetch(), XMLHttpRequest, WebSocket, and EventSource. Critical for API-heavy applications and real-time features.
Source Value | Typical Use Case |
|---|---|
| API calls to own domain |
| Calls to a specific external API |
| WebSocket connections |
| Any HTTPS API endpoint (broad; acceptable if no sensitive endpoints) |
| Google Analytics data collection |
frame-ancestors
Replaces the older X-Frame-Options header. Defines which origins are allowed to embed this page in a <frame>, <iframe>, <object>, or <embed>.
Value | Effect | Use Case |
|---|---|---|
| Nobody can iframe this page | ✅ Strongest; use for login pages, dashboards |
| Only same origin can iframe | Most common |
| Specific partner origin only | Controlled embedding |
| Anyone can iframe | ❌ Enables clickjacking |
Note: frame-ancestors cannot be set via <meta> tag — it only works as an HTTP response header. This tool outputs it correctly in the header format but omits it from the meta tag output.
base-uri
Restricts what URLs can appear in a <base> element. Base tag injection allows attackers to rewrite all relative URLs on the page to point to a malicious server.
Value | Recommendation |
|---|---|
| ✅ Recommended — restrict to own origin |
| ✅ If you don't use |
Omitted | ❌ Falls through to |
form-action
Controls where HTML forms can submit data. Without this directive, a stored XSS that injects a <form action="https://evil.com"> can silently exfiltrate user input.
Value | Effect |
|---|---|
| Forms can only submit to the same origin |
| Forms submit to a specific API endpoint |
| No form submissions allowed (rare; API-only apps) |
Step 3 — Add Custom Sources
For any directive, click "Custom source" and type a hostname, URL pattern, or scheme. The tool appends it to the selected sources list and immediately updates the live output. Valid formats include:
Format | Example | Matches |
|---|---|---|
Exact host |
| That exact host on HTTPS |
Host with wildcard |
| Any subdomain of example.com |
Scheme only |
| Any URL on HTTPS |
Path-specific |
| That path only |
Step 4 — Toggle Report-Only Mode
The Report-Only header toggle switches the output between:
Content-Security-Policy:— enforcing mode (browsers block violations)Content-Security-Policy-Report-Only:— monitoring mode (browsers log violations, do not block)
Both can be deployed simultaneously in production — Report-Only for testing a new stricter policy while keeping the enforcing policy unchanged.
Step 5 — Copy Your Output
The tool generates three output formats simultaneously. Choose based on your deployment context:
Output Format | When to Use |
|---|---|
CSP policy string | Paste into nginx |
HTTP response header | Full header line ready to paste into server config files verbatim |
HTML | When you cannot modify HTTP headers — static site generators, CDNs without header control, email HTML |
Step 6 — Apply Deployment Tips
The tool surfaces three critical reminders on every policy generation:
Start with Report-Only and monitor violations before switching to enforcing mode
Use nonces instead of
'unsafe-inline'for scripts — nonces prevent inline script injection even if an attacker can inject HTMLSet
frame-ancestors 'none'unless your application legitimately needs to be embedded in iframes