CSP Header Builder
Free online Content Security Policy (CSP) header builder and generator. Visually configure CSP directives, validate policies, and test URLs against your security rules.
default-src 'self'<meta http-equiv="Content-Security-Policy" content="default-src 'self'">What Is a CSP Header Builder?
Content Security Policy (CSP) is a browser security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by defining which sources of content are allowed to load on a web page. A CSP Header Builder provides a visual interface to construct valid CSP header strings without memorizing directive syntax. You toggle directives on or off, select allowed source values like 'self', 'unsafe-inline', or specific domains, and the tool generates the correct header string in real time. It also warns you about conflicting or insecure configurations, such as combining 'unsafe-inline' with 'strict-dynamic', or using 'unsafe-eval' which re-enables dangerous JavaScript execution.
How to Use the CSP Header Builder
- Enable the directives you need by toggling them on. Start with 'default-src' as a baseline fallback policy.
- For each enabled directive, click the source values you want to allow (e.g., 'self', https:, data:). Selected values are highlighted in blue.
- Add custom domains by typing them into the input field and pressing Enter or clicking Add (e.g., https://cdn.example.com).
- Review any yellow warnings that appear — they indicate conflicting or insecure directive combinations.
- Copy the generated CSP header string or HTML meta tag using the copy buttons.
- Optionally, enter a test URL to check whether it would be allowed or blocked by your current policy.
Common Use Cases
- Hardening Web Application Security — Build a strict CSP policy for your production website to block inline scripts, restrict resource origins, and prevent XSS attacks. Start with a restrictive default-src 'none' and selectively allow only the sources your application needs.
- Migrating to CSP Incrementally — When adding CSP to an existing application, use the builder to experiment with different directive combinations, identify which sources your app requires, and gradually tighten the policy without breaking functionality.
- Debugging CSP Violations — When your browser console shows CSP violation errors, use the test URL feature to check whether a specific resource URL is allowed by your current policy and adjust directives accordingly.
- Generating Meta Tags for Static Sites — For static sites hosted on platforms where you cannot set HTTP headers, copy the generated HTML meta tag to embed the CSP policy directly in your HTML document's head section.
FAQ
What is the difference between CSP as an HTTP header and a meta tag?
Both methods deliver the same policy to the browser. The HTTP header (Content-Security-Policy) is set by the server and supports all directives. The HTML meta tag (meta http-equiv Content-Security-Policy) is embedded in the page and works for most directives, but does not support frame-ancestors, report-uri, or sandbox. The HTTP header is generally preferred because it is applied before the page HTML is parsed.
What does 'strict-dynamic' do and why does it ignore 'unsafe-inline'?
'strict-dynamic' tells the browser to trust scripts loaded by already-trusted scripts (via nonce or hash), even from new origins. When 'strict-dynamic' is present, the browser ignores 'unsafe-inline' and host-based allowlists for script-src. This is by design — it enables a nonce-based approach where only explicitly nonced scripts run, and they can dynamically load additional scripts.
Should I always set default-src?
Yes, default-src acts as a fallback for any directive you don't explicitly set. If you define script-src but not style-src, the browser uses default-src for styles. Setting default-src to 'none' or 'self' establishes a secure baseline that you then relax per directive as needed.
Why is 'unsafe-eval' dangerous?
'unsafe-eval' allows the use of eval(), new Function(), setTimeout with strings, and other dynamic code execution APIs. These are common XSS attack vectors because they let an attacker execute arbitrary JavaScript if they can inject a string into your application. Avoid 'unsafe-eval' unless absolutely required by your framework or libraries.
Does this tool validate the CSP header against the official specification?
This tool generates syntactically correct CSP headers and warns about common conflicting or insecure combinations. However, it does not perform exhaustive W3C specification validation. For production deployment, test your CSP in a staging environment using the browser's developer console to catch any violations.