SSL & Security

CSP Builder

Policy Builder

Build Your CSP

Configure each directive below and copy the generated CSP policy in your preferred format.
Start from a Preset
Global Options
Directives0 / 13 configured

Fallback for all fetch directives not explicitly setKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid sources for JavaScriptKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid sources for stylesheetsKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid sources for imagesKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid targets for fetch, XHR, WebSocketKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid sources for fontsKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid sources for nested browsing contexts (iframe)Keywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid sources for audio and videoKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid sources for plugins (Flash, etc.)Keywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid sources for Worker and SharedWorker scriptsKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid endpoints for form submissionsKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Valid parents that may embed this pageKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Restricts URLs for <base> elementKeywords
'none'
'self'
'unsafe-inline'
'unsafe-eval'
'strict-dynamic'
'report-sample'
↵ Enter

Generated CSP Policy

Content-Security-Policy — configure directives above to update

HTTP Header
Content-Security-Policy: upgrade-insecure-requests
HTML Meta Tag
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
Raw Policy String
upgrade-insecure-requests

Tool features

Build production-ready Content Security Policies
4 features

Visual Builder

Configure each CSP directive with checkboxes and inputs

Policy Presets

Start from Strict, Moderate, Development, or WordPress templates

Validation

Highlights conflicts and insecure combinations automatically

Export Formats

Copy as HTTP header, meta tag, or raw CSP string

What is a Content Security Policy & how it works

How a CSP decides what a page may load

A Content Security Policy (CSP) is a response header that tells the browser exactly which sources a page may load scripts, styles, images, frames and connections from. Anything not on the list is blocked, which stops most cross-site scripting (XSS) and content-injection attacks.

A policy is a list of directives, each with its allowed sources. default-src sets the fallback, and specific directives such as script-src or img-src override it. Because a strict policy can break a site, the usual path is to deploy it in Report-Only mode first, fix what it reports, then enforce it.

'self'
Allows resources from the page’s own origin (scheme, host and port).
nonce / hash
Lets specific inline scripts run without allowing all inline code.
Report-Only
Logs violations without blocking, so you can test a policy safely.

How to use this tool

Build and roll out a CSP in four steps
1
Start from a preset
Pick Strict, Moderate, Development or WordPress as a starting point.
2
Adjust the directives
Add the domains your site really loads scripts, styles, fonts, images and APIs from.
3
Test in Report-Only
Enable Report-Only mode and deploy the header to watch for violations without breaking anything.
4
Enforce it
Once the console is clean, switch to the enforcing Content-Security-Policy header, or use the meta tag if you cannot set headers.

Related tools

Keep debugging with tools from the same suite
4 tools
OCSP Checker
Check SSL certificate revocation status using the Online Certificate Status Protocol (OCSP)
Secure Header Checker
Check security headers like CSP, HSTS, X-Frame-Options, and more with security scoring
HSTS Checker
Check HTTP Strict Transport Security (HSTS) header configuration and preload status
CORS Tester
Test Cross-Origin Resource Sharing (CORS) configuration and headers

Frequently asked questions

Common questions about Content Security Policy
5 Q&A

Use the HTTP header when you can. The <meta http-equiv="Content-Security-Policy"> tag works for most directives, but it cannot set frame-ancestors, report-uri or sandbox, and it cannot be used for Report-Only mode.

The policy is blocking something the page needs, often an inline script, a CDN, an analytics domain or a font host. Open the browser console to see each blocked resource and the directive that blocked it, then add that source.

Avoid it in script-src: it re-enables the inline scripts that XSS relies on. Move inline code into files, or allow specific blocks with a nonce or hash. It is less risky in style-src.

It is the fallback for every fetch directive you do not set explicitly. A common baseline is default-src 'self', then opening up only the specific directives that need more.

Deploy the header, then run the site through the CSP Checker to see the policy the server actually sends and how strong it is.