Content Security Policy Builder

An HTTP header controlling which resources a browser can load, preventing XSS and data injection attacks.

Enforced blocks violations. Report-only allows them but reports — useful for testing before enforcement.

unsafe-inline allows exploitable inline scripts. unsafe-eval enables dynamic code execution. Both significantly weaken CSP protection.

Yes, the Content Security Policy Builder is 100% free with no registration, no hidden fees, and no usage limits. All processing happens locally in your browser, ensuring complete privacy.

Yes, the Content Security Policy Builder is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the Content Security Policy Builder in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

The Content Security Policy Builder works in all modern browsers including Chrome, Firefox, Safari, Edge, and Opera. For the best experience, use the latest version of your preferred browser.

default-src is the fallback directive: it sets the allowed sources for any resource type you have not explicitly configured, so locking it to 'none' or 'self' creates a deny-by-default baseline. script-src is a specific override that controls only where JavaScript can load from, and it takes precedence over default-src for scripts. Because scripts are the main vector for cross-site scripting, you almost always want a tight script-src even if default-src is already restrictive — for example default-src 'self' with a separate script-src 'self' that adds a nonce. Other per-type directives like style-src, img-src, and connect-src work the same way, narrowing one resource type while default-src covers the rest. This builder lets you set default-src once and override individual directives only where needed.

On Nginx you add the policy inside a server or location block with add_header Content-Security-Policy "your policy here" always; the always flag ensures the header is sent even on error responses like 404s. On Apache you use Header set Content-Security-Policy "your policy here" inside the relevant VirtualHost or .htaccess, with mod_headers enabled. In both cases the value is the full directive string, and you reload the server for it to take effect. Getting the syntax exactly right by hand is error-prone, so this builder generates ready-made copy-paste snippets for Nginx, Apache, Express.js, and Next.js from whatever policy you configure. Build your directives visually, pick your server, and paste the generated block straight into your config.

A CSP can be delivered two ways: as a Content-Security-Policy HTTP response header or as an HTML <meta http-equiv="Content-Security-Policy"> tag in the page head. The meta-tag method is convenient when you cannot edit server config, but the spec deliberately ignores certain directives in that context. frame-ancestors, report-uri, report-to, and sandbox only work when sent as a real HTTP header, because they must be known before the page renders or relate to response-level reporting. If clickjacking protection matters to you, frame-ancestors must come from the header, not the meta tag. This builder lets you switch between header and meta output formats and warns you which directives get dropped in meta mode, so you do not ship a policy that silently loses its anti-clickjacking protection.

Each change recalculates a strictness score out of 100, graded Weak, Fair, Good, or Excellent. The score rewards genuinely protective choices rather than just the presence of a policy. You earn the most points for a restrictive default-src ('none' beats 'self'), a script-src with no unsafe-inline or unsafe-eval keywords, object-src 'none', and a defined frame-ancestors. Adding base-uri, form-action, a clean style-src, and other narrowing directives nudges the number up further, while wildcard sources and the unsafe keywords hold it down. Enabling report-only mode lowers the score slightly, since a report-only header offers no real blocking until you enforce it. The Analysis tab itemizes exactly what is driving your score, so you can see which weak spots to fix to move from Good to Excellent.

A nonce is a random token your server generates per page load and places both in the CSP and on each trusted <script> tag; the browser only runs scripts carrying the matching nonce. A hash works similarly but identifies a specific inline script by its sha256 fingerprint, with no per-request token needed. Both let you keep necessary inline scripts while removing 'unsafe-inline', which would otherwise allow any injected inline script to run and defeat your XSS protection. Pairing a nonce with 'strict-dynamic' also lets trusted scripts load their own dependencies without whitelisting every domain. This builder includes nonce and sha256 placeholder source values and recommends switching from unsafe-inline to a nonce- or hash-based approach. Configure script-src with a nonce placeholder here, then wire the real token in on your server.