What is a Content Security Policy and what does it protect against?

A Content Security Policy (CSP) is an HTTP response header that tells the browser which sources of script, style, image, font and other content it may load. Its main job is to blunt cross-site scripting (XSS): even if an attacker injects a tag, a policy like default-src 'self'; script-src 'self' stops the browser from running anything that did not come from your own origin. It also limits where forms can post and which sites may frame your page.

What does default-src 'self' actually do?

default-src is the fallback for every fetch directive you did not list explicitly. Setting default-src 'self' means script, style, image, font, connect and frame requests all default to your own origin (same scheme, host and port) unless a more specific directive overrides it. So default-src 'self'; img-src 'self' data: allows same-origin everything plus inline data: images. Always set default-src as your baseline; without it, unlisted directives allow everything.

Why is 'unsafe-inline' dangerous?

'unsafe-inline' lets the page run inline blocks and inline event handlers like onclick. That is exactly the channel XSS exploits, so allowing it on script-src removes most of CSP's protection: an injected inline script will execute. The safe alternative is a per-request nonce ('nonce-abc123') or a hash ('sha256-...') so only the inline blocks you authored run. On style-src the risk is lower but still real, since inline styles can leak data via CSS.

When should I use a meta tag instead of a response header?

Prefer the response header. It applies to the whole document including the initial parse, and it is the only place where frame-ancestors, report-uri/report-to and sandbox work at all. The form is a fallback for static hosting where you cannot set headers, but it is ignored for those header-only directives and does not protect resources requested before the tag is parsed. This generator gives you both so you can pick per deployment.

How do I roll out CSP without breaking my site?

Start in report-only mode. Send Content-Security-Policy-Report-Only with a report-to endpoint instead of the enforcing header: the browser reports what the policy would block but loads everything as normal. Watch the reports for a week, fold every legitimate source into the policy, then switch the header name to Content-Security-Policy to enforce. The report-only preset here gives you that starting point, and the strict preset is a good enforcement target.

What is the difference between this and a CSP auditor?

This generator builds a policy from scratch out of directive toggles and presets, for when you are writing a new CSP. A CSP auditor goes the other way: you paste an existing policy and it reports gaps such as missing object-src or weak wildcards. They pair well, build here, then run the result through the auditor before shipping. The internal link to the CSP Policy Auditor lets you do exactly that.

Ship a first CSP on a new app

You are launching a single-page app and want a baseline policy before go-live. Start from the strict preset, add your API origin to connect-src and your CDN to script-src, and copy the header line into your server config. You get a working default-src 'self' policy in under a minute instead of hand-typing directives and discovering typos in production.

Whitelist a third-party widget

Marketing just added an analytics snippet and a chat widget, and the console is full of CSP violations. Paste the widget's domains into the relevant directives (script-src for its JS, connect-src for its API, frame-src if it embeds an iframe), regenerate, and ship the updated header. The live warnings remind you not to widen script-src to a bare https: wildcard just to make the errors go away.

Stage a report-only rollout

You inherited a legacy site with inline scripts everywhere and cannot risk breaking it. Use the report-only preset to emit a Content-Security-Policy-Report-Only header, wire up a report endpoint, and collect violations for a week. Fold each legitimate source into the policy here, then flip to the enforcing header name once the reports go quiet.

Generate the right form for static hosting

Your site is on a static host where you cannot set response headers, so you need the meta-tag form instead. Build the policy, copy the output, and drop it into the document head. The note under the meta output reminds you that frame-ancestors will not work there, so you handle clickjacking another way.

CSP Generator - build a Content-Security-Policy header

Build a Content-Security-Policy from directive toggles, get the header line, meta tag and Nginx snippet, with live unsafe-inline warnings, browser-only

Runs locally
Category Developer & DevOps
Best for Checking file type, size, metadata, and obvious mismatch signals before sharing.

Presets

Report-Only mode

Observe violations without blocking — use during rollout

Directives

default-src

script-src

style-src

img-src

connect-src

font-src

frame-src

object-src

base-uri

form-action

frame-ancestors

Warnings

No risky sources detected.

Header line

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'

HTML <meta> tag

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'">

frame-ancestors, report-uri and sandbox only work as a response header, not in <meta>.

Nginx add_header

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'" always;

What this tool does

A Content Security Policy generator that builds the header from choices instead of asking you to memorize syntax. Toggle sources on each directive ('self', 'none', 'unsafe-inline', 'unsafe-eval', https:, data:), paste your own CDN or API domains, and watch the policy assemble in real time. The tool emits three drop-in forms at once: a raw Content-Security-Policy header line, an HTML meta http-equiv tag, and an Nginx add_header directive, each with one-click copy. Three presets cover the common starting points: a strict same-origin lockdown, a permissive set that allows jsdelivr, unpkg and Google Fonts, and a report-only policy for observing violations before you enforce. Whenever a choice weakens the policy, such as 'unsafe-inline' on script-src or a bare https: wildcard, an inline warning explains why and what to use instead. Everything runs in your browser, nothing is uploaded, and the policy round-trips through a shareable URL.

Tool details

Input: Files + Text; The page exposes text boxes, numeric controls, file pickers, or structured inputs depending on the tool.
Output: Live result + Copy; The result area focuses on usable output, with copy, download, or preview actions when supported.
Privacy: Browser-side processing; The main tool logic does not call an external API, so inputs normally stay in the current tab.
Save / share: Shareable URL state; Key settings are encoded in the URL so another person can reopen the same setup.
Performance budget: Initial JS <= 9 KB; No WASM budget is declared, keeping the tool quick to open on mobile.
Best fit: Developer & DevOps · Developer; Category and role tags drive related tools, internal links, and quick fit checks.

How to use

1. Input

Paste or drop your content into the tool panel.
2. Process

Click the button. All processing is local in your browser.
3. Copy / Download

Copy the result or download to disk in one click.

How CSP Generator fits into your work

Use it before upload, handoff, archive, support review, or any moment where a file needs one local check before it leaves your machine.

File jobs

Checking file type, size, metadata, and obvious mismatch signals before sharing.
Preparing mixed folders for upload, archive, intake, or review.
Keeping sensitive files in the browser instead of sending them to an account-based service.

File checks

Do not treat the extension alone as proof of the real file type.
Review metadata before a file goes to customers, vendors, or a public page.
Keep the original file until the copied, converted, or exported result is verified.

Good next steps

These links move the current task into a more complete workflow.

Real-world use cases

Ship a first CSP on a new app
You are launching a single-page app and want a baseline policy before go-live. Start from the strict preset, add your API origin to connect-src and your CDN to script-src, and copy the header line into your server config. You get a working default-src 'self' policy in under a minute instead of hand-typing directives and discovering typos in production.
Whitelist a third-party widget
Marketing just added an analytics snippet and a chat widget, and the console is full of CSP violations. Paste the widget's domains into the relevant directives (script-src for its JS, connect-src for its API, frame-src if it embeds an iframe), regenerate, and ship the updated header. The live warnings remind you not to widen script-src to a bare https: wildcard just to make the errors go away.
Stage a report-only rollout
You inherited a legacy site with inline scripts everywhere and cannot risk breaking it. Use the report-only preset to emit a Content-Security-Policy-Report-Only header, wire up a report endpoint, and collect violations for a week. Fold each legitimate source into the policy here, then flip to the enforcing header name once the reports go quiet.
Generate the right form for static hosting
Your site is on a static host where you cannot set response headers, so you need the meta-tag form instead. Build the policy, copy the <meta http-equiv> output, and drop it into the document head. The note under the meta output reminds you that frame-ancestors will not work there, so you handle clickjacking another way.

Common pitfalls

Leaving 'unsafe-inline' on script-src to silence console errors. It re-opens the XSS hole CSP was meant to close. Move inline code into files, or authorize it with a per-request nonce or a sha256 hash instead.
Forgetting default-src, so unlisted directives silently allow everything. A policy of just script-src 'self' still lets images, fonts and connections load from anywhere. Always set default-src 'self' as the baseline and override per directive.
Putting frame-ancestors or report-uri in a <meta> tag. Those are header-only directives and the browser ignores them in meta. Use the response-header output for anything beyond the basic fetch directives.

Privacy

The whole generator is plain JavaScript running in your browser tab. Directive choices, custom domains and the generated policy never leave the page, and there is no analytics on what you build. The one thing to know: the shareable URL encodes your policy in the query string, so a link pasted into chat records those directives in the recipient server's access log. A CSP is not secret, but if it reveals internal asset hosts you would rather keep quiet, use the copy button instead of sharing the URL.

FAQ

Tool combos

Folks in your role tend to reach for these alongside this tool.

Developer

Browse all tools for this role

CSP Generator - build a Content-Security-Policy header

What this tool does

Tool details

How to use

1. Input

2. Process

3. Copy / Download

How CSP Generator fits into your work

File jobs

File checks

Good next steps

Real-world use cases

Ship a first CSP on a new app

Whitelist a third-party widget

Stage a report-only rollout

Generate the right form for static hosting

Common pitfalls

Privacy

FAQ

CSP Policy Auditor

HTTP Security Header Auditor

Meta Tag Generator

robots.txt Generator

AI Eval Planner

API Key Generator

ASCII Table Generator

ASCII Table Reference

awk + sed Cheatsheet

AWS CLI Cheatsheet

Barcode Generator

Number Base Converter