Toolypet
Security Tools/CSP Builder

CSP Builder

Build Content-Security-Policy headers visually

Presets

Directives

Default fallback for other directives

Controls allowed JavaScript sources

Controls allowed CSS sources

Controls allowed image sources

Controls allowed font sources

Controls allowed fetch/XHR/WebSocket targets

Controls allowed iframe sources

Controls allowed plugin sources (Flash, etc.)

Restricts URLs for <base> element

Restricts form submission targets

Controls who can embed this page

Upgrade HTTP to HTTPS automatically

Options

When enabled, violations are reported but not blocked. Useful for testing.

Generated CSP Header

Content-Security-Policy: default-src 'self'

Implementation Examples

add_header Content-Security-Policy "default-src 'self'";
Header set Content-Security-Policy "default-src 'self'"
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

CSP Builder Guide

Learn how to create Content-Security-Policy headers to protect your website

What is Content-Security-Policy?

Content-Security-Policy (CSP) is an HTTP response header that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks. It allows you to specify which sources of content are allowed to be loaded on your website, giving you fine-grained control over scripts, styles, images, and other resources.

How to Use

  1. Choose a preset (Strict, Moderate, or Relaxed) as a starting point
  2. Enable and configure individual directives based on your needs
  3. Review security warnings and adjust settings accordingly
  4. Copy the generated header and add it to your web server configuration

Best Practices

Frequently Asked Questions

What happens if I set CSP too strictly?

If your CSP is too strict, legitimate resources may be blocked, breaking your website's functionality. This is why it's recommended to start with Report-Only mode. In this mode, violations are reported to your server (if you configure a report-uri) but not actually blocked, allowing you to identify issues before enforcing the policy.

What's the difference between 'self' and 'none'?

'self' allows content only from the same origin (same protocol, host, and port) as your website. 'none' blocks all content of that type. For example, object-src 'none' prevents all plugins (Flash, Java, etc.) from loading, which is a security best practice.

Why is 'unsafe-inline' considered dangerous?

'unsafe-inline' allows inline scripts and styles, which defeats much of CSP's XSS protection. Attackers who can inject HTML can also inject inline scripts. Instead, use nonces (script-src 'nonce-random123') or hashes (script-src 'sha256-...') to allow specific inline scripts while blocking injected ones.

How do I allow Google Analytics or other third-party scripts?

Add the specific domain to your script-src directive. For Google Analytics, you might need: script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com. Also add their domains to connect-src for API calls and img-src for tracking pixels.

Can CSP replace other security headers?

No, CSP complements other security headers. You should also use: X-Content-Type-Options: nosniff, X-Frame-Options (though frame-ancestors in CSP can replace this), X-XSS-Protection, Strict-Transport-Security (HSTS), and Referrer-Policy. Each header addresses different security concerns.

Related Tools

Security Headers

Analyze HTTP security headers

Password Generator

Generate secure passwords

SHA Hash Generator

Generate SHA hashes