01
Security-focused warnings
Flags unsafe-inline, unsafe-eval and wildcard sources that can weaken CSP.
Start typing to search 227 tools.
Generator
Ready
CSP Policy Builder
Build a Content-Security-Policy header with presets, source directives, Report-Only mode, security warnings, and copy-ready HTTP, nginx, Apache and meta-tag output.
Build CSP directives individually Start from strict, WordPress, API or static-site presets Switch between enforce and Report-Only modes Validate nonce, hash, scheme and host source expressions
Test new policies with Report-Only first. Avoid unsafe-inline and unsafe-eval whenever possible.
Private browser processing. Your input is processed on this device and is not sent to the Trexmi server.
INPUT Policy mode
Generated CSP policy
HTTP header, policy value, warnings, and optional HTML meta tag.
About the tool
What CSP Policy Builder does
CSP Policy Builder generates a deployable Content-Security-Policy for websites and web applications. Configure directives such as default-src, script-src, style-src, img-src, connect-src, frame-src, object-src, base-uri, form-action and frame-ancestors.
Use Content-Security-Policy-Report-Only to observe violations without blocking resources, then move to enforcement after the policy is verified. The builder accepts common CSP keywords, hosts, schemes, nonces and SHA-256/384/512 hash sources and warns about settings that commonly weaken a policy.
Output is available as a normal HTTP header, an nginx add_header directive, an Apache Header always set line, an HTML meta tag where supported, or the raw policy value.
How to use
- Choose mode. Start with Report-Only when introducing CSP to a live site.
- Select a preset. Use it as a starting point, not a final policy.
- Add required sources. Include only the origins, schemes, nonces or hashes your application needs.
- Review warnings. Remove unnecessary wildcards, unsafe-inline and unsafe-eval.
- Deploy and test. Copy the correct server snippet and inspect browser CSP reports before enforcement.
Built for the task
Why use CSP Policy Builder?
Focused controls, predictable output, and a workflow designed around this exact transformation.
02
Practical directives
Configure the directives most web applications need without manually assembling the header.
03
Report-Only workflow
Test a policy before it starts blocking production resources.
04
Deployment-ready output
Copy HTTP, nginx, Apache, meta-tag or raw policy output.
Useful answers
Questions about CSP Policy Builder
Practical details about input, output, privacy, limits, and the best way to use this tool.
01 Should I start with CSP Report-Only?
For an existing production site, usually yes. Report-Only lets you collect violations without blocking resources while you tune the policy.
02 Can CSP be placed in a meta tag?
An enforcing CSP can be delivered with a meta element, but not every directive is supported there. Report-Only must be delivered through an HTTP header.
03 Why is unsafe-inline dangerous?
It broadly allows inline script or style execution. Prefer nonces or hashes where practical, especially for script-src.
04 What does default-src do?
It acts as a fallback for many fetch directives when a more specific directive such as script-src or img-src is absent.
05 What is a CSP nonce?
A nonce is an unpredictable per-response value placed in the policy and on an allowed inline script or style element.
06 Can I paste a SHA-256 hash into script-src?
Yes. CSP supports SHA-256, SHA-384 and SHA-512 hash sources using the required quoted syntax.
07 Does CSP replace HTTPS?
No. CSP and HTTPS address different risks. A production site should generally use HTTPS and a carefully tested CSP.
08 Will this tool know every domain my site needs?
No. Use browser developer tools and CSP violation reports to identify the resources your actual application loads.
Examples
Strict same-origin baseline
A restrictive baseline for sites that serve their own scripts and styles.
Input
default-src 'self'; object-src 'none'; base-uri 'self'
Output
Content-Security-Policy header
Report-Only rollout
Observe violations before switching the same policy to enforcement.
Input
Policy mode: Report-Only
Output
Content-Security-Policy-Report-Only header
Build CSP in Report-Only before enforcement
A restrictive policy deployed without testing can break scripts, fonts, images, API calls or embedded content. For established sites, start with Content-Security-Policy-Report-Only, observe violations, adjust required sources and then switch to enforcement.
Important CSP directives
default-src provides a fallback. script-src and style-src control executable scripts and styles. connect-src affects fetch, XHR and WebSocket connections. frame-ancestors controls which pages may embed your site, while object-src none is a common hardening choice.
Nonces and hashes
Nonces and hashes can authorize specific inline resources without broadly enabling unsafe-inline. Nonces must be unpredictable and regenerated for every HTTP response. Hashes must match the exact inline content.
nginx, Apache and meta-tag output
Choose the deployment format that matches your environment. HTTP headers are the most complete delivery method. A meta CSP can be useful when server headers cannot be configured, but it has limitations and cannot deliver Report-Only.
Related Trexmi tools
Build other response headers with HTTP Header Builder, inspect TLS with SSL Certificate Checker, or calculate script hashes with SHA-256 Generator.
Reference
Review the current MDN Content Security Policy documentation before deploying a production policy.