nexora.tools // module active

CSP Generator

Build a Content-Security-Policy header for your website to help prevent XSS attacks.

Sign in to save scan history and unlock your dashboard.

Directive builder

Pick directives through a simple UI, no syntax to memorize.

Domain allowlisting

Add trusted script/style/image sources visually.

Copy-ready header

Outputs a header you can paste straight into your server config.

Report-only mode tips

Guidance on rolling out safely without breaking your site.

default-src

Fallback for all resource types

script-src

JavaScript sources

style-src

CSS sources

img-src

Image sources

font-src

Font sources

connect-src

fetch/XHR/WebSocket targets

frame-src

Iframe sources

object-src

Flash/plugins (usually 'none')

media-src

Audio/video sources

base-uri

Allowed <base> targets

form-action

Allowed form submit targets

Content-Security-Policy Header

default-src 'self';

Add this as a Content-Security-Policy response header, or as a <meta http-equiv="Content-Security-Policy"> tag.
Ask AI to explain this

How it works

A Content-Security-Policy header tells the browser exactly which sources are allowed to load scripts, styles, images, and other resources on your page. This tool builds a working policy from the directives you pick, so you don't have to write the syntax by hand.

CSP is one of the strongest defenses against XSS: even if an attacker manages to inject a script tag, a correctly scoped policy stops the browser from executing it.

Frequently asked questions

Will the generated policy work immediately without testing?

Test it in report-only mode first (Content-Security-Policy-Report-Only header) before enforcing it — a policy that's slightly too strict can silently block legitimate scripts, fonts, or embedded content.

Why is 'unsafe-inline' discouraged in the script-src directive?

Allowing it defeats much of CSP's protection against XSS, since it permits any inline script to run — including ones an attacker injects. Using nonces or hashes for legitimate inline scripts is the safer alternative.

Do I need a different CSP for every page on my site?

Not necessarily — most sites can use one policy site-wide, adding specific source exceptions only for pages that genuinely need additional third-party resources (like a payment page embedding a processor's script).

Related tools