What is Content-Security-Policy?

Content-Security-Policy (CSP) is an HTTP response header that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks. It works by specifying which content sources are allowed to load on your web page.

Without CSP

Vulnerable State

Browsers load resources from any origin
Site exposed to malicious script injection
No control over content sources
Higher XSS attack risk

With CSP

Protected State

Strict control over allowed domains
Blocks unauthorized scripts automatically
Granular resource permissions
Defense-in-depth security layer

Why Use a CSP Header?

XSS Protection

Block unauthorized scripts from executing on your pages, preventing attackers from injecting malicious code through vulnerabilities.

Data Theft Prevention

Control where your page can send data via fetch, XHR, or WebSocket connections, preventing data exfiltration.

Clickjacking Defense

Use frame-ancestors directive to prevent your site from being embedded in malicious iframes for clickjacking attacks.

Mixed Content Prevention

Force HTTPS for all resources with upgrade-insecure-requests, eliminating mixed content vulnerabilities.

How This Tool Helps

Writing CSP headers manually is error-prone and requires memorizing directive names and source syntax. This visual builder lets you toggle directives, click source values, and instantly see the generated header in the format you need — whether it's raw HTTP, Apache, Nginx, or PHP.

Time-saving benefit: Configure complex security policies in minutes instead of hours, with real-time validation and format conversion built in.

Table of Contents

1. What is Content-Security-Policy?
2. How to Use the CSP Header Generator
3. Features
4. Frequently Asked Questions

How to Use the CSP Header Generator

Choose a Starting Point

Select a preset template to start with a common configuration, or begin with Blank to build from scratch. Available presets include Strict, Basic Website, SPA + API, WordPress, E-commerce, and CDN-heavy configurations.

Configure Directives

Toggle directives on or off by clicking their checkbox or header row. When a directive is enabled, you can:

Click quick source buttons ('self', 'none', 'unsafe-inline', etc.) to add common values
Type a custom domain (e.g., cdn.example.com, *.googleapis.com) and click Add
Click a source button again to remove it
Click the × button on custom domain tags to remove them

Review Warnings

The tool automatically analyzes your policy and shows security warnings. Red warnings indicate significant security risks, yellow warnings suggest improvements, and blue notices provide helpful information.

Choose Output Format

Select the output format that matches your web server:

Raw - The plain HTTP header value
Apache - For .htaccess or Apache configuration files
Nginx - For nginx.conf server blocks
Meta Tag - For HTML <meta> tags (note: Report-Only is not supported)
PHP - For PHP header() function calls

Copy and Deploy

Click the Copy button to copy the generated header to your clipboard. Consider enabling Report-Only mode first to test your policy without blocking any resources.

Best practice: Always test with Report-Only mode in production before enforcing the policy to identify potential issues without breaking functionality.

Features

Visual Directive Builder

Each CSP directive is displayed as an interactive row with a toggle switch. Enable a directive to reveal its source configuration panel with quick-add buttons and custom domain input. Directives are organized into four categories: Fetch, Document, Navigation, and Other.

Interactive directive builder with toggle switches and quick-add source buttons

16 Supported Directives

Fetch Directives

Control where different types of resources can be loaded from:

default-src - Fallback for all fetch directives
script-src - JavaScript sources
style-src - CSS stylesheets
img-src - Images and favicons
connect-src - Fetch, XHR, WebSocket connections
font-src - Web fonts
object-src - Plugins (Flash, Java applets)
media-src - Audio and video
frame-src - Nested browsing contexts (iframes)
worker-src - Web Workers and Service Workers
manifest-src - Web app manifests

Document & Navigation Directives

Control document behavior and navigation:

base-uri - Restricts URLs that can appear in <base> element
form-action - Valid endpoints for form submissions
frame-ancestors - Valid parents that may embed this page (clickjacking protection)

Important: frame-ancestors cannot be set via meta tag — it requires an HTTP header.

Other Directives

Additional security enhancements:

upgrade-insecure-requests - Automatically upgrade HTTP to HTTPS
block-all-mixed-content - Block all mixed content (deprecated, use upgrade-insecure-requests)
report-uri - Endpoint to send violation reports (deprecated, use report-to)

Preset Templates

Strict

Maximum security configuration with minimal allowed sources. Best for high-security applications.

Basic Website

Balanced policy for standard websites with self-hosted resources and common CDNs.

SPA + API

Optimized for Single Page Applications with API backends and dynamic module loading.

WordPress

Pre-configured for WordPress sites with common plugin and theme requirements.

E-commerce

Includes Stripe, PayPal, and payment gateway integrations for online stores.

CDN-heavy

Configured for sites using Google Analytics, fonts, and multiple CDN providers.

Smart Source Management

The tool handles source value logic automatically to prevent configuration errors:

Mutual Exclusivity

Selecting 'none' automatically clears all other sources since they are mutually exclusive.

Auto-replacement

Adding any source when 'none' is active automatically removes 'none' first.

Duplicate Prevention

Duplicate sources are automatically detected and prevented from being added.

Security Analysis

Real-time warnings alert you to potential security issues in your CSP configuration:

Critical warning: Using 'unsafe-inline' or 'unsafe-eval' in script-src significantly weakens XSS protection.

Security recommendation: Missing object-src or base-uri directives may leave vulnerabilities open.

Best practice note: Wildcard usage (e.g., https://*) defeats CSP protection by allowing all domains.

Multiple Output Formats

Format	Use Case	Report-Only Support
Raw HTTP	Plain header value for any server	Yes
Apache	.htaccess or httpd.conf files	Yes
Nginx	nginx.conf server blocks	Yes
Meta Tag	HTML <meta> element	No
PHP	PHP header() function	Yes

Meta tag limitation: When using the Meta Tag format with Report-Only mode active, a note is displayed since meta tags cannot use Content-Security-Policy-Report-Only.

Your Data Stays Private

All processing happens in your browser with zero server communication:

No Server Requests

Your policy configuration never leaves your device. All generation and validation happens locally using JavaScript.

No Tracking

We don't collect or store any usage data, configuration details, or analytics about your CSP policies.

Frequently Asked Questions

What is the difference between Content-Security-Policy and Content-Security-Policy-Report-Only?

Content-Security-Policy enforces the policy and blocks resources that violate it. Content-Security-Policy-Report-Only only reports violations without blocking anything.

Recommended workflow: Use Report-Only mode first to test your policy and identify issues before enforcing it in production.

This two-phase approach prevents accidentally breaking functionality while allowing you to monitor violation reports and refine your policy safely.

Why should I always include object-src 'none'?

The object-src directive controls plugins like Flash and Java applets. These plugins can execute arbitrary code and bypass other CSP protections.

Setting object-src to 'none' blocks all plugin content, which is recommended since:

Modern websites rarely need plugins
Flash and Java applets are deprecated and insecure
Plugins can circumvent CSP script-src restrictions
Most browsers are phasing out plugin support

Is 'unsafe-inline' really that dangerous?

Yes. When you allow 'unsafe-inline' in script-src, any inline script on your page can execute — including scripts injected by an attacker through XSS vulnerabilities. This significantly weakens CSP protection.

With 'unsafe-inline'

Vulnerable

All inline scripts execute
Injected scripts run freely
XSS protection weakened

With nonces/hashes

Protected

Only whitelisted scripts run
Injected scripts blocked
Strong XSS protection

Better alternatives: Use nonces or hashes instead, which allow specific inline scripts while blocking injected ones.

What does default-src do?

default-src acts as a fallback for all fetch directives that are not explicitly set. For example, if you set default-src 'self' but don't set img-src, images will only load from your own domain.

Key principle: Any directive you explicitly set overrides default-src for that resource type.

Example:

CSP with default-src fallback

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' cdn.example.com;
  img-src *;

/* Result:
 * - Scripts: 'self' + cdn.example.com (explicit)
 * - Images: * (explicit)
 * - Styles: 'self' (falls back to default-src)
 * - Fonts: 'self' (falls back to default-src)
 */

Can I use the meta tag format for all CSP features?

No. The HTML meta tag approach has significant limitations:

Cannot use Report-Only mode
Cannot set frame-ancestors directive
Cannot use report-uri or report-to
Cannot use sandbox directive

Recommendation: For full CSP functionality, use HTTP headers configured on your web server (Apache, Nginx, etc.).

Meta tags are useful for quick testing or when you don't have server configuration access, but HTTP headers provide complete CSP capabilities.

What is 'strict-dynamic' and when should I use it?

'strict-dynamic' tells the browser to trust scripts that are loaded by already-trusted scripts. This is useful for modern applications that dynamically load JavaScript modules.

Benefits

Simplifies CSP for dynamic apps

Works with module bundlers
Supports dynamic imports
Reduces policy complexity

How It Works

Trust propagation model

Host-based allowlists ignored
Works with nonce-based policies
Scripts load other trusted scripts

Best for: Single Page Applications (SPAs), React/Vue/Angular apps, and sites using Webpack or similar bundlers.