CSP Generator
Build a Content-Security-Policy header with common directives, cleaned source values, and warnings for risky settings.
Generated CSP Header
Review Before Deployment
- style-src contains 'unsafe-inline'. Confirm that inline styles are required.
Privacy Note
CSP generation happens locally inside your browser. The generated policy is a starting point, not proof of a secure deployment. Test it with Content-Security-Policy-Report-Only first where practical, inspect violations, and confirm every required resource still works.
Building Content Security Policy Headers Without Guesswork
A Content Security Policy tells supporting browsers which resource locations may be used by a page. A carefully tested policy can reduce the impact of some injection attacks and unwanted resource loading.
CSP is defense in depth. It does not replace output encoding, safe DOM handling, dependency updates, authentication controls, or other application security work. An overly broad or untested policy can provide little protection or break legitimate features.
This generator covers common fetch directives and several document directives. It normalizes extra whitespace and highlights a few risky values, but it cannot understand every resource or runtime behaviour in your application.
How to Use the CSP Generator
- Configure your CSP directives and allowed resource sources.
- Customize policies for scripts, styles, images, APIs, fonts, and frames.
- Review any warnings and copy the generated header.
- Test with Report-Only where practical before enforcing it in production.
Common CSP Directives
- default-src: Default fallback policy for all resource types.
- script-src: Allowed JavaScript sources and third-party scripts.
- style-src: Allowed CSS stylesheets and inline styles.
- img-src: Allowed image sources and CDN assets.
- connect-src: Allowed API endpoints and network requests.
- font-src: Allowed web font providers and font assets.
- frame-src: Allowed sources for frames loaded by the page. This differs from frame-ancestors, which controls who may embed your page.
Common Use Cases
- Building and testing a browser resource-loading policy.
- Reducing the impact of some script-injection attacks.
- Reviewing a policy before production enforcement.
- Restricting third-party resource loading.
- Restricting resource sources in Next.js and React applications.
- Creating CSP headers for web applications and dashboards.
- Managing allowed CDN and script domains.
Example Content Security Policy 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'; frame-ancestors 'none'; form-action 'self';
Why CSP Headers Matter
- Resource control: Limit where supported browsers may load content from.
- Script restrictions: Limit approved script sources and inline execution patterns.
- Third-party review: Make external script, style, image, and frame sources explicit.
- Report-Only testing: Find policy violations before switching to enforcement.
Frequently Asked Questions
What is Content Security Policy?
Content Security Policy is a browser security feature that controls which resources websites are allowed to load and execute.
Why are CSP headers important?
A well-designed CSP can reduce the impact of some cross-site scripting and resource-injection attacks. It is an additional browser control, not a complete security solution.
What does 'self' mean in CSP?
'self' allows resources from the same origin as the current website.
Is this useful for Next.js and React applications?
Yes. CSP headers are commonly used with Next.js, React, frontend dashboards, and other browser-delivered web applications.
Should I use Report-Only first?
For an existing site, Report-Only can help reveal blocked resources before enforcement. Review reports carefully because report collection and browser coverage vary.
Is CSP generation processed on the server?
No. CSP header generation happens entirely inside your browser.