Enable or disable tooltips

CSP Generator Logo

CSP Generator

default-src
HighCommon
Function: Serves as a fallback for other CSP fetch directives. Sets default policy for loading content.
Purpose: Provides a baseline security policy that other directives can override with more specific rules.
Risk Level: High
Fetch Directives
Function: Control loading of external resources like scripts, styles, images, and media files
Purpose: These directives manage where your website can fetch various types of content from, preventing malicious resource injection attacks
Fetch
'self'
LowCommon
Function: Allows resources from the same origin (same protocol, domain, and port).
Purpose: Permits loading resources only from your own domain, providing good security with functionality.
Risk Level: Low
Keyword Sources
Function: Special CSP keywords that define broad source permissions
Purpose: These keywords provide standardized ways to allow or restrict content, offering common security patterns
Keyword
https://example.com
LowCommon
Function: Allows resources from a specific HTTPS domain.
Purpose: Permits loading resources only from a trusted, specific domain over HTTPS.
Risk Level: Low
Host Sources
Function: Domain and host-based source specifications
Purpose: These sources specify exact domains or IP addresses that are trusted to serve content
Host

📚 Complete CSP Reference Guide & Documentation

Content Security Policy (CSP) is a powerful security mechanism that helps prevent cross-site scripting (XSS) attacks, data injection attacks, and other code injection vulnerabilities. This comprehensive guide covers all CSP directives and source expressions to help you create robust security policies for your web applications.

CSP allows website administrators to control which resources are allowed to load on their web pages. By implementing a well-configured CSP, you can significantly reduce the attack surface of your application and protect your users from malicious content injection.

CSP Overview

How Content Security Policy Works

HTTP Header Implementation

CSP policies are typically implemented via the Content-Security-Policy HTTP header. This is the most secure and flexible method for deploying CSP policies.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.com
HTML Meta Tag Alternative

CSP can also be implemented using HTML meta tags, though this method has some limitations compared to HTTP headers.

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

Benefits of Implementing CSP

🛡️
XSS Protection

Prevents cross-site scripting attacks by controlling script execution

🔒
Data Injection Defense

Blocks unauthorized data injection and code execution attempts

📊
Security Monitoring

Provides detailed reporting on policy violations and attacks

Key CSP Directives Explained

DirectivePurposeExample Usage
default-srcFallback for all resource typesdefault-src 'self';
script-srcControls JavaScript executionscript-src 'self' 'unsafe-inline'
style-srcControls CSS stylesheet loadingstyle-src 'self' https://fonts.googleapis.com
img-srcControls image source loadingimg-src 'self' data: https:
frame-ancestorsControls iframe embedding permissionsframe-ancestors 'none'

CSP Implementation Best Practices

  1. Start with Report-Only

    Begin with Content-Security-Policy-Report-Only to test your policy

  2. Use Restrictive Defaults

    Start with default-src 'self' and add exceptions as needed

  3. Monitor Violations

    Set up CSP reporting endpoints to track policy violations

  4. Gradual Enforcement

    Move to enforcement mode after thorough testing and validation

Why use this web app?

🛠️ Tools
  • Real-time interactive CSP policy generation and preview
  • Comprehensive tooltips with security explanations
  • Security risk assessments for each source type
💡 Educational Content
  • Detailed explanations for every CSP directive
  • Real-world examples and implementation guidance
  • Common pitfalls and how to avoid them

CSP Directives Reference

CSP directives define the policy for different types of resources. Each directive controls what sources are allowed for specific resource types, providing granular control over your website's security policy.

Document Directives
Function: Control document-level behavior and base document settings
Purpose: These directives manage fundamental document properties and prevent manipulation of base URLs and document structure

Document Directives

1
base-uri
MediumCommon

Restricts the URLs which can be used in a document's <base> element.

Purpose: Prevents attackers from changing the base URL to redirect relative URLs to malicious sites.
Examples:
  • base-uri 'self'
  • base-uri 'none'
Fetch Directives
Function: Control loading of external resources like scripts, styles, images, and media files
Purpose: These directives manage where your website can fetch various types of content from, preventing malicious resource injection attacks

Fetch Directives

18
child-src
HighCommon

Defines valid sources for web workers and nested browsing contexts loaded using elements such as <frame> and <iframe>.

Purpose: Controls where child contexts can be loaded from, preventing malicious iframe injections.
Examples:
  • child-src 'self'
  • child-src 'none'
connect-src
HighCommon

Restricts the URLs which can be loaded using script interfaces like XMLHttpRequest, WebSocket, fetch(), etc.

Purpose: Prevents scripts from making unauthorized network requests to external APIs or services.
Examples:
  • connect-src 'self'
  • connect-src https://api.example.com
default-src
HighCommon

Serves as a fallback for other CSP fetch directives. Sets default policy for loading content.

Purpose: Provides a baseline security policy that other directives can override with more specific rules.
Examples:
  • default-src 'self'
  • default-src 'none'
fenced-frame-src
Medium

Specifies valid sources for nested browsing contexts loading using the Fenced Frame API.

Purpose: Controls loading of privacy-focused fenced frames, typically used in advertising contexts.
Examples:
  • fenced-frame-src 'self'
  • fenced-frame-src https://ads.example.com
font-src
LowCommon

Specifies valid sources for fonts loaded using @font-face.

Purpose: Prevents loading of malicious fonts that could be used for attacks or unauthorized tracking.
Examples:
  • font-src 'self'
  • font-src 'self' https://fonts.googleapis.com
frame-src
HighCommon

Specifies valid sources for nested browsing contexts loading using <frame> and <iframe>.

Purpose: Controls which external content can be embedded in frames on your page.
Examples:
  • frame-src 'none'
  • frame-src 'self'
img-src
MediumCommon

Specifies valid sources of images and favicons.

Purpose: Prevents loading of unauthorized images that could be used for tracking or attacks.
Examples:
  • img-src 'self'
  • img-src 'self' data: https:
manifest-src
Low

Specifies valid sources of application manifest files.

Purpose: Controls where web app manifests can be loaded from for Progressive Web Apps.
Examples:
  • manifest-src 'self'
  • manifest-src https://cdn.example.com
media-src
MediumCommon

Specifies valid sources for loading media using <audio>, <video> and <track> elements.

Purpose: Prevents unauthorized media content from being loaded, which could contain malicious payloads.
Examples:
  • media-src 'self'
  • media-src https://media.example.com
object-src
HighCommon

Specifies valid sources for <object>, <embed>, and <applet> elements.

Purpose: Prevents loading of potentially dangerous plugins and embedded objects.
Examples:
  • object-src 'none'
  • object-src 'self'
prefetch-src
DeprecatedLow

Specifies valid sources to be prefetched or prerendered.

Purpose: Controls which resources can be prefetched, preventing unauthorized resource loading.
Examples:
  • prefetch-src 'self'
  • prefetch-src https://cdn.example.com
script-src
HighCommon

Specifies valid sources for JavaScript including inline event handlers.

Purpose: Prevents execution of unauthorized scripts, the primary defense against XSS attacks.
Examples:
  • script-src 'self'
  • script-src 'self' 'unsafe-inline'
script-src-attr
High

Specifies valid sources for JavaScript inline event handlers.

Purpose: Controls inline event handlers separately from other scripts for fine-grained security control.
Examples:
  • script-src-attr 'none'
  • script-src-attr 'unsafe-inline'
script-src-elem
High

Specifies valid sources for JavaScript <script> elements.

Purpose: Controls script elements separately from inline handlers for more precise security policies.
Examples:
  • script-src-elem 'self'
  • script-src-elem https://cdn.example.com
style-src
MediumCommon

Specifies valid sources for CSS stylesheets.

Purpose: Prevents loading of unauthorized stylesheets that could be used for attacks or data exfiltration.
Examples:
  • style-src 'self'
  • style-src 'self' 'unsafe-inline'
style-src-attr
Medium

Specifies valid sources for inline styles applied to individual DOM elements.

Purpose: Controls inline style attributes separately from stylesheets for enhanced security granularity.
Examples:
  • style-src-attr 'none'
  • style-src-attr 'unsafe-inline'
style-src-elem
Medium

Specifies valid sources for stylesheets <style> elements and <link> elements with rel='stylesheet'.

Purpose: Controls stylesheet elements separately from inline styles for precise security control.
Examples:
  • style-src-elem 'self'
  • style-src-elem https://cdn.example.com
worker-src
HighCommon

Specifies valid sources for Worker, SharedWorker, or ServiceWorker scripts.

Purpose: Controls where web workers can be loaded from, preventing unauthorized background script execution.
Examples:
  • worker-src 'self'
  • worker-src 'none'
Navigation Directives
Function: Control navigation and redirection behavior
Purpose: These directives manage where users can navigate to and how forms can be submitted, preventing malicious redirects

Navigation Directives

3
form-action
HighCommon

Restricts the URLs which can be used as the target of a form submission.

Purpose: Prevents forms from being submitted to unauthorized endpoints that could steal user data.
Examples:
  • form-action 'self'
  • form-action https://secure-submit.example.com
frame-ancestors
HighCommon

Specifies valid parents that may embed a page using <frame>, <iframe>, <object>, etc.

Purpose: Prevents clickjacking attacks by controlling which sites can embed your content in frames.
Examples:
  • frame-ancestors 'none'
  • frame-ancestors 'self'
navigate-to
DeprecatedMedium

Restricts the URLs to which a document can initiate navigation by any means.

Purpose: Prevents unauthorized redirects and navigation to malicious sites.
Examples:
  • navigate-to 'self'
  • navigate-to https://trusted-site.com
Reporting Directives
Function: Configure CSP violation reporting and monitoring
Purpose: These directives set up violation reporting to help monitor and debug CSP policy issues

Reporting Directives

2
report-to
Low

Defines a reporting group which CSP violations should be sent to.

Purpose: Enables monitoring and debugging of CSP violations by sending reports to specified endpoints.
Examples:
  • report-to csp-endpoint
  • report-to default
report-uri
DeprecatedLowCommon

Instructs the user agent to report attempts to violate the Content Security Policy. Superseded by report-to directive.

Purpose: Provides violation reporting for monitoring and improving your CSP implementation.
Examples:
  • report-uri https://example.com/csp-report
  • report-uri /csp-violation-report-endpoint/
Other Directives
Function: Miscellaneous security directives and special controls
Purpose: These directives provide additional security controls that don't fit into other categories

Other Directives

8
block-all-mixed-content
DeprecatedLowCommon

Prevents loading any assets using HTTP when the page is loaded using HTTPS.

Purpose: Ensures all content is loaded securely over HTTPS, preventing mixed content vulnerabilities.
Examples:
  • block-all-mixed-content
plugin-types
DeprecatedMedium

Restricts the set of plugins that can be embedded into a document by limiting the types of resources which can be loaded.

Purpose: Controls which plugin MIME types can be loaded, reducing attack surface from plugins.
Examples:
  • plugin-types application/pdf
  • plugin-types application/pdf application/x-shockwave-flash
referrer
DeprecatedLowCommon

Controls the referrer information sent when following links from the document.

Purpose: Manages privacy by controlling what referrer information is shared with external sites.
Examples:
  • referrer no-referrer
  • referrer origin
require-sri-for
DeprecatedHigh

Requires Subresource Integrity for scripts or styles on the page.

Purpose: Ensures that external scripts and styles haven't been tampered with by requiring integrity checks.
Examples:
  • require-sri-for script
  • require-sri-for style
require-trusted-types-for
High

Enforces Trusted Types at the DOM sink level.

Purpose: Prevents DOM-based XSS attacks by requiring trusted types for dangerous DOM operations.
Examples:
  • require-trusted-types-for 'script'
sandbox
High

Enables a sandbox for the requested resource similar to the iframe sandbox attribute.

Purpose: Restricts page capabilities to prevent various attacks, similar to iframe sandboxing.
Examples:
  • sandbox
  • sandbox allow-scripts
trusted-types
High

Specifies an allowlist of Trusted Types policy names created by Document.createElement().

Purpose: Enables Trusted Types API to prevent DOM-based XSS by controlling dangerous DOM operations.
Examples:
  • trusted-types myPolicy
  • trusted-types policy1 policy2
upgrade-insecure-requests
LowCommon

Instructs user agents to treat all of a site's insecure URLs as though they have been replaced with secure URLs.

Purpose: Automatically upgrades HTTP requests to HTTPS for enhanced security without breaking functionality.
Examples:
  • upgrade-insecure-requests

CSP Source Expressions Reference

Source expressions define which locations are allowed to serve resources. Understanding these expressions is crucial for creating effective CSP policies that balance security with functionality.

Keyword Sources
Function: Special CSP keywords that define broad source permissions
Purpose: These keywords provide standardized ways to allow or restrict content, offering common security patterns

Keyword Sources

6
'none'
LowCommon

Blocks all sources. Nothing will be allowed to load from any source.

Purpose: Maximum security - completely disables loading of the specified resource type.
Usage Examples:
  • object-src 'none'
  • base-uri 'none'
'self'
LowCommon

Allows resources from the same origin (same protocol, domain, and port).

Purpose: Permits loading resources only from your own domain, providing good security with functionality.
Usage Examples:
  • script-src 'self'
  • style-src 'self'
'unsafe-inline'
HighCommon

Allows inline scripts, styles, and event handlers. Not recommended for security.

Purpose: Enables inline code execution but significantly weakens CSP protection against XSS attacks.
Usage Examples:
  • script-src 'self' 'unsafe-inline'
  • style-src 'self' 'unsafe-inline'
'unsafe-eval'
High

Allows the use of eval() and similar dynamic code execution methods.

Purpose: Enables dynamic code evaluation but creates significant security vulnerabilities.
Usage Examples:
  • script-src 'self' 'unsafe-eval'
'unsafe-hashes'
Medium

Allows inline event handlers that match specified hashes.

Purpose: Permits specific inline event handlers while maintaining some security through hash verification.
Usage Examples:
  • script-src 'self' 'unsafe-hashes' 'sha256-abc123...'
'strict-dynamic'
Medium

Allows scripts loaded by already-trusted scripts to load additional scripts.

Purpose: Enables dynamic script loading while maintaining security through trust propagation.
Usage Examples:
  • script-src 'strict-dynamic' 'nonce-abc123'
  • script-src 'strict-dynamic' 'sha256-xyz789'
Wildcard Sources
Function: Pattern-based source matching with wildcards
Purpose: These sources use wildcards to match multiple hosts or subdomains efficiently

Wildcard Sources

2
*
High

Allows resources from any source. Not recommended for most directives.

Purpose: Completely permissive - allows loading from anywhere, providing no security protection.
Usage Examples:
  • img-src *
  • media-src *
https://*.example.com
LowCommon

Allows resources from any subdomain of a specific domain over HTTPS.

Purpose: Permits loading from all subdomains of a trusted domain while maintaining HTTPS encryption.
Usage Examples:
  • script-src https://*.googleapis.com
  • img-src https://*.example.com
Scheme Sources
Function: Protocol-based source specifications (http, https, data, etc.)
Purpose: These sources allow content from specific protocols, useful for controlling how resources are loaded

Scheme Sources

6
data:
LowCommon

Allows data: URIs (base64 encoded inline resources).

Purpose: Permits embedded data URIs, commonly used for small images or inline SVGs.
Usage Examples:
  • img-src 'self' data:
  • font-src 'self' data:
blob:
LowCommon

Allows blob: URIs (binary large objects created by JavaScript).

Purpose: Enables dynamically created binary content, often used for file downloads or media streams.
Usage Examples:
  • media-src 'self' blob:
  • img-src 'self' blob:
http:
High

Allows any HTTP URL. Not recommended due to security risks.

Purpose: Permits unencrypted HTTP connections, which can be intercepted or modified.
Usage Examples:
  • img-src https: http:
  • default-src https: http:
https:
MediumCommon

Allows any HTTPS URL. More secure than HTTP but still very permissive.

Purpose: Permits encrypted HTTPS connections from any domain, providing transport security.
Usage Examples:
  • default-src 'self' https:
  • img-src https:
ws:
High

Allows WebSocket connections over HTTP (unencrypted).

Purpose: Enables real-time communication via unencrypted WebSockets (not recommended).
Usage Examples:
  • connect-src 'self' ws://localhost:3000
wss:
LowCommon

Allows WebSocket connections over HTTPS (encrypted).

Purpose: Enables secure real-time communication via encrypted WebSockets.
Usage Examples:
  • connect-src 'self' wss://secure-websocket.example.com
Host Sources
Function: Domain and host-based source specifications
Purpose: These sources specify exact domains or IP addresses that are trusted to serve content

Host Sources

2
https://example.com
LowCommon

Allows resources from a specific HTTPS domain.

Purpose: Permits loading resources only from a trusted, specific domain over HTTPS.
Usage Examples:
  • script-src 'self' https://cdn.example.com
  • connect-src https://api.example.com
https://api.example.com
LowCommon

Allows resources from a specific API endpoint over HTTPS.

Purpose: Enables secure communication with a specific API or service endpoint.
Usage Examples:
  • connect-src 'self' https://api.example.com
  • script-src https://api.example.com

CSP Implementation Best Practices

✅ Recommended Practices

  • Start with a restrictive policy and gradually relax as needed
  • Use 'self' instead of wildcard (*) sources when possible
  • Implement nonces for inline scripts instead of 'unsafe-inline'
  • Use hash-based sources for static inline content
  • Enable CSP reporting to monitor policy violations
  • Test policies thoroughly in report-only mode first
  • Regularly review and update your CSP as your site evolves

⚠️ Security Warnings

  • Avoid 'unsafe-inline' and 'unsafe-eval' in production
  • Don't use wildcard (*) sources unless absolutely necessary
  • Be careful with data: URIs as they can be exploited
  • Monitor CSP reports for potential attacks
  • Don't disable CSP entirely for debugging purposes
  • Validate that your CSP doesn't break legitimate functionality
  • Keep CSP policies up to date with security best practices

Frequently Asked Questions

What is Content Security Policy (CSP)?

Content Security Policy (CSP) is a security standard that helps prevent XSS attacks by controlling which resources are allowed to load on a webpage. It works by defining a whitelist of trusted sources for different types of content.

How do I implement CSP on my website?

CSP can be implemented using HTTP headers (Content-Security-Policy) or HTML meta tags. The header method is preferred as it's more secure and flexible. Start with a report-only policy to test before enforcing.

What's the difference between 'self' and specific domains?

'self' allows resources from the same origin (protocol, domain, port), while specific domains allow resources from those exact domains. 'self' is generally more secure and maintainable.

Why should I avoid 'unsafe-inline' and 'unsafe-eval'?

These directives significantly weaken CSP protection by allowing inline scripts and dynamic code evaluation, which are common attack vectors for XSS. Use nonces or hashes instead for inline content.