CSP Header Builder

How to Use the CSP Header Builder

Each row in the builder represents one CSP directive. Type source values directly into the input field, or click the quick-add buttons below each field to insert common sources like 'self', 'none', https:, or data:. The generated header appears in the output area at the bottom and updates as you add or remove sources. When your policy is ready, copy it as a raw HTTP header value for your server configuration, or as an HTML meta tag for embedding directly in your page.

Start with default-src 'none' to block everything by default, then add specific directives to allow only the resources your site actually needs. This allowlist approach is more secure than starting permissive and trying to block individual threats. Test your policy in report-only mode before enforcing it to avoid accidentally breaking functionality.

Understanding CSP Directives

The Content-Security-Policy specification defines over a dozen directives, each controlling a specific type of resource. The default-src directive serves as the catch-all fallback. If you set default-src 'self' but do not define script-src, scripts will be allowed only from your own origin. Once you explicitly set a directive like script-src, it completely overrides default-src for that resource type. This means you need to include 'self' in the specific directive if you still want to load scripts from your own domain.

Common Source Values Explained

The 'self' keyword matches the current origin, including the same scheme, host, and port. The 'none' keyword blocks all sources for that directive. 'unsafe-inline' allows inline scripts and styles, which weakens your XSS protection considerably. 'unsafe-eval' permits dynamic code execution through eval() and related functions. The https: scheme source allows any resource served over HTTPS. The data: scheme allows data URIs, which are commonly used for inline images and fonts but can also be exploited for script injection when combined with other directives.

Building a Secure Baseline Policy

A solid starting point for most sites is: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'. This blocks everything by default and only allows your own origin for the most common resource types. It also prevents your site from being framed by other domains. From this baseline, add specific domains for CDNs, analytics, or third-party widgets as needed. Each addition should be deliberate and documented.

Deploying Your CSP

Most web servers and frameworks support setting custom response headers. In Nginx, add the header in your server block: add_header Content-Security-Policy "your policy here" always;. In Apache, use Header set Content-Security-Policy "your policy here". In Rails, configure the CSP in an initializer using Rails.application.configure { config.content_security_policy { |p| ... } }. Cloud platforms like Cloudflare, AWS CloudFront, and Vercel also support custom response headers in their configuration files. Always test in report-only mode first by using Content-Security-Policy-Report-Only instead of Content-Security-Policy.

Frequently Asked Questions

What is a Content-Security-Policy header?

A Content-Security-Policy header is an HTTP response header that tells the browser which sources of content are allowed to load on a page. By specifying approved origins for scripts, styles, images, fonts, and other resources, CSP prevents cross-site scripting, clickjacking, and other code injection attacks. The browser enforces the policy by blocking any resource that does not match the declared sources.

What does default-src control?

The default-src directive acts as a fallback for any fetch directive that is not explicitly set. If you define default-src 'self' and do not set a separate script-src, the browser will only allow scripts from your own origin. Setting default-src 'none' and then adding individual directives is the most restrictive and secure approach.

When should I use unsafe-inline or unsafe-eval?

Avoid 'unsafe-inline' and 'unsafe-eval' whenever possible because they weaken CSP by allowing inline scripts and dynamic code evaluation. If your application relies on inline scripts, migrate to nonce-based or hash-based CSP instead. Use 'unsafe-inline' only as a temporary measure during migration.

What is the difference between the HTTP header and the meta tag?

Both deliver the same policy, but the HTTP header is set by the server and applies before the page renders. The meta tag is parsed when the browser reaches it in the HTML. The HTTP header supports all directives including frame-ancestors and report-uri, while the meta tag does not. For full protection, prefer the HTTP header.

How do I test my CSP without breaking my site?

Use the Content-Security-Policy-Report-Only header instead of Content-Security-Policy. This tells the browser to report violations without actually blocking anything. Set a report-uri endpoint to collect violation reports and review them before switching to enforcement mode.