./prontouso.com

SECURITY

Content Security Policy Generator

Fill in sources for each CSP directive to generate a ready-to-use Content-Security-Policy header value and meta tag.

Tool statusRuns in your browser
Preview
prontouso://security/csp-generator
HEADER · NGINX · APACHE · METAAUTO GENERATE

Start from a profile

Pick a starting point, then fine-tune each directive below. Switching profiles keeps whatever you've already typed in directives it doesn't mention.

POLICY
default-src
Fallback source list for any directive not set explicitly below.
'self'
Quick add
script-src
Where JavaScript may be loaded and executed from.
'self'
Quick add
style-src
Where stylesheets and inline <style> may come from.
'self'
Quick add
img-src
Where images may be loaded from.
'self'data:
Quick add
font-src
Where @font-face fonts may be loaded from.
'self'
Quick add
connect-src
Allowed targets for fetch, XHR, WebSocket and EventSource.
'self'
Quick add
worker-src
Where Worker/SharedWorker/ServiceWorker scripts may load from.
Off — the browser uses the applicable fallback, when this directive has one.
frame-src
Allowed sources for embedded <frame>/<iframe> content.
'none'
Quick add
object-src
Allowed sources for <object>/<embed>/<applet>. Leave at 'none' unless you need Flash-era plugins.
'none'
Quick add
base-uri
Restricts what a <base> tag is allowed to point to, blocking a common injection trick.
'self'
Quick add
form-action
Allowed targets for HTML form submissions.
'self'
Quick add
frame-ancestors
Who may embed this page in a frame — the CSP replacement for X-Frame-Options.
'none'
Quick add
Violation reporting
● NO LOGIN · PROCESSED LOCALLY

Generated policy

Pick the format that matches where you're deploying this.

OUTPUT
Policy health

Automatic checks against common CSP mistakes.

✓No obvious weaknesses found in the enabled directives.
HTTP header
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-src 'none'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none';
Test an origin

Check whether a given URL would be allowed under the directive you pick, using the policy above.

Resource type
URL to test
Rollout checklist
1. Ship this Report-Only header — nothing on the site breaks yet.
2. Collect reports for several days of real traffic before touching anything.
3. Adjust the directives above for any legitimate resource that shows up blocked.
4. Once reports come back clean, switch the mode to Enforce.

How it works

  1. Enter your input

    Fill in the values, paste your text, or upload the file this tool works with.

  2. See results instantly

    Most tools update live as you type; a few use a single button. Either way, the result appears right on this page.

  3. Use your results

    Copy, download, or share what the tool produces — you're always in control of the output.

Privacy and processing — Runs locally in your browser. This tool does not upload your input.

What is Content Security Policy Generator?

The Content-Security-Policy Generator is a tool for building a CSP from twelve grouped directives, with four starting profiles, automatic detection of common weaknesses, violation-reporting support (Reporting-Endpoints and the legacy report-uri), export as an HTTP header, Nginx, Apache, or a <meta> tag, and a tester that checks whether a specific URL would be allowed or blocked by the policy you built.

UNDERSTAND THE TOOL

How to build a Content-Security-Policy: profiles, tester, and violation reporting

Pick a starting profile (Starter, SPA, Strict, or Locked down), fine-tune each directive grouped into Core policy, Fetch destinations, and Navigation, and watch the automatic security warnings. Switch between Report-Only and Enforce, export as an HTTP header, Nginx, Apache, or a <meta> tag, and test whether a specific URL would be blocked before you ship it.

The four starting profiles

"Starter" is a same-origin baseline for a typical server-rendered site. "SPA" builds on that and adds XHR/WebSocket and web-worker sources, for a single-page app. "Strict (nonce)" uses a 'nonce-{RANDOM}' placeholder in script-src that your server must replace with a fresh nonce on every request — the strongest protection against injected scripts. "Locked down" builds on Strict and also blocks the <base> tag, the tightest of the four. Switching profiles only touches the directives that profile defines — whatever you've already typed in directives it doesn't mention stays untouched.

Twelve directives grouped into three blocks

"Core policy" covers default-src (the fallback for any directive not set explicitly below), script-src, and style-src. "Fetch destinations" covers img-src, font-src, connect-src, and worker-src. "Navigation & embedding" covers frame-src, object-src, base-uri, form-action, and frame-ancestors. Every enabled directive gets "Quick add" chips with common values, plus a field for a custom source. A directive enabled with no sources at all emits 'none'; a disabled directive is omitted from the policy entirely, and the browser falls back to the applicable directive (usually default-src) instead.

Report-Only or Enforce, and the four output formats

"Report-Only" generates the Content-Security-Policy-Report-Only header, which collects violations without blocking anything — safe to ship first. "Enforce" generates the actual Content-Security-Policy header, which actively blocks anything outside the policy. Output can be exported as a plain HTTP header, a ready-made Nginx add_header directive, an Apache Header directive, or an HTML <meta> tag. Choosing the <meta> format switches the mode to Enforce automatically, because a CSP meta tag always enforces and can't carry frame-ancestors or reporting directives.

Automatic policy-health warnings

The tool checks the enabled directives against six common problems: a wildcard source (*), which cancels out most of what CSP protects against; 'unsafe-eval', which permits eval() and new Function(); 'unsafe-inline', which allows inline script or style; object-src not locked to 'none', the classic Flash/plugin injection path; a missing base-uri, which lets an attacker hijack relative URLs with an injected <base> tag; and a missing frame-ancestors, which leaves the page open to clickjacking. With none of those present, the policy is flagged as having no obvious weaknesses.

Violation reporting: Reporting-Endpoints and the legacy report-uri

Turning on "Send violation reports" and entering the endpoint URL (https:// only, or http:// on localhost for testing) and a Report-To group name makes the tool emit the Reporting-Endpoints header alongside the report-to directive in the policy. The "Also emit the legacy report-uri directive" option adds report-uri as a fallback channel for browsers that don't yet support the newer Reporting API.

Testing whether a specific URL would be allowed

The "Test an origin" section picks a resource type and a URL, and evaluates the outcome against the current policy following CSP's own fallback chain (a directive with no rule of its own falls back to default-src). The result shows whether the URL would be blocked (no sources, no match, or just 'self' — in which case the tool can't know your page's real origin and asks you to check manually) or allowed (wildcard, the https: scheme, or an exact origin match). It's a deliberately simplified approximation that doesn't model nonces, hashes, or path-based sources.

Privacy and the tester's limits

Building the policy, the warnings, and the origin tester all run in your browser — nothing is sent to a server. Even so, the tester is a simplified approximation of browsers' actual CSP algorithm, not a full engine: use Report-Only mode and your browser's developer tools to confirm real-world behavior before enforcing the policy in production.

Frequently Asked Questions

Which profile should I start from?

Starter suits a typical server-rendered site with same-origin assets. SPA adds sources for XHR/WebSocket calls and web workers, for a single-page app. Strict (nonce) gives the strongest protection against injected scripts, but requires your server to generate and inject a fresh nonce on every response. Locked down builds on Strict and also blocks the <base> tag.

What does the {RANDOM} placeholder in the Strict profile mean?

It's a placeholder — your server needs to replace 'nonce-{RANDOM}' with a fresh random value on every request, and apply that same value to the nonce attribute of the <script> tags that should be allowed.

Why does choosing the <meta> output switch the mode to Enforce on its own?

Because a CSP <meta> tag always enforces, never works in Report-Only, and doesn't support frame-ancestors or the violation-reporting directives — the tool adjusts the mode automatically to reflect that limitation.

Are disabled directives left out of the final policy?

Yes — a disabled directive is omitted from the policy entirely, and the browser falls back to the applicable directive (usually default-src) instead. That's different from a directive enabled with no sources at all, which explicitly emits 'none' and blocks everything of that type.

Is the origin tester 100% accurate?

No — it's a simplified approximation meant for a quick sanity check, and it doesn't model nonces, hashes, or path-based sources. Use it as a first signal, but confirm real-world behavior by shipping the policy in Report-Only mode and watching the browser console.

How does violation reporting work?

The endpoint URL and group name you enter generate the Reporting-Endpoints header and the report-to directive in the policy, which modern browsers use to send violation reports. Enabling the legacy report-uri directive adds a second reporting channel for browsers that don't yet support the newer Reporting API.

Do the policy-health warnings block the policy from generating?

No — the warnings are informational only. The policy still generates, copies, and downloads normally even with flagged weaknesses; it's up to you to decide whether each one is acceptable for your case.

What's the difference between switching profiles and editing a directive by hand?

Applying a profile only changes the directives that profile explicitly defines — any directive you'd already adjusted manually that the profile doesn't mention stays exactly as it was.

Related Tools