Content Security Policy Generator

How to use the csp generator

1. Fill in the directives you need. Start with default-src and add more specific ones such as script-src and img-src.
2. Separate sources with spaces: keywords such as 'self', schemes such as data: and hosts such as cdn.example.com. Leave a box empty to leave that directive out.
3. Choose how to show the result: an HTTP header, a report-only header or a meta tag.
4. Read the check row and the warnings, then copy the result into your server config or HTML head.

How a Content Security Policy works

A Content Security Policy is an HTTP header or HTML meta tag that tells the browser which origins are permitted to load resources. The syntax is a semicolon-separated list of directives, where each directive has a name followed by one or more source expressions. For example, default-src 'self'; script-src 'self' https://cdn.example.com; restricts all fetches to the same origin by default but allows scripts from a specific CDN.

The default-src directive acts as a fallback. If you do not specify img-src, the browser applies the default-src value to images. Directives like frame-ancestors have no fallback and must be declared explicitly if you want to control who can embed your page.

Common CSP directives reference

This table summarizes the most frequently used directives you can configure with this content security policy generator.

Header versus meta tag delivery

You can deliver a CSP via the Content-Security-Policy HTTP response header or through a <meta http-equiv="Content-Security-Policy"> tag in the HTML head. The HTTP header is preferred because it supports every directive, including frame-ancestors and reporting endpoints.

The meta tag approach is useful when you cannot modify server headers, such as on static hosting platforms. However, browsers ignore frame-ancestors, report-uri, report-to and sandbox when they appear in a meta tag. This content security policy generator outputs both formats so you can choose the appropriate delivery method.

Why unsafe-inline and unsafe-eval are dangerous

Adding 'unsafe-inline' to script-src or style-src permits inline event handlers, javascript: URIs and embedded script blocks. This defeats the primary purpose of CSP, which is to prevent injected code from executing. Instead of 'unsafe-inline', move scripts to external files or use nonces and hashes.

The 'unsafe-eval' keyword allows functions like eval(), setTimeout() with string arguments and new Function(). These patterns let attackers execute arbitrary strings as code. A strict policy omits both keywords entirely. When you add them using this tool, the warnings section highlights the risk so you can make an informed decision.

Deploying and testing your policy

Start with a Content-Security-Policy-Report-Only header to collect violation reports without blocking legitimate resources. Once you confirm the policy does not break your site, switch to the enforcing Content-Security-Policy header. You can verify your deployed headers using a security headers checker.

Keep your policy as tight as possible. Avoid the wildcard * in default-src because it allows resources from any origin. Specify exact domains rather than broad scheme sources like https:. Review your CSP periodically as third-party dependencies change, and consider pairing it with other protections like HSTS and X-Frame-Options.

Worked examples