Content Security Policy Generator — 2026 Tutorial

✓ Last tested: June 2026 · Verified against W3C CSP Level 3 Spec & OWASP Guidelines

1. Field Notes: The E-Commerce Site That Blocked Its Own Checkout

Deploying a Content Security Policy is terrifying the first time you do it.

A few years ago, an e-commerce client tried to rush their SOC2 compliance. They copy-pasted a "strict" CSP header they found on StackOverflow and deployed it directly to production on a Friday afternoon.

Within minutes, their Stripe checkout iframe vanished. Google Analytics stopped tracking. Their live chat widget collapsed into a console error. The CSP they copied was blocking all third-party scripts and connections (script-src 'self'; connect-src 'self'). Because they deployed it using the enforcement header rather than the Report-Only header, they inadvertently launched a self-inflicted Denial of Service attack on their own revenue pipeline.

We had to frantically rollback the server config, and then do it the right way: We implemented Content-Security-Policy-Report-Only, pointed it at a logging endpoint, and watched thousands of legitimate violations pour in. Over the next week, we meticulously mapped out every legitimate third-party service they used (Stripe, Segment, Zendesk) and whitelisted them in the policy.

The lesson? Never guess your CSP. Always observe, build, and test before enforcing.

---

2. What Is a Content Security Policy and Why You Need One?

A Content Security Policy (CSP) is an HTTP response header that allows site administrators to declare approved sources of content that the browser may load.

By default, browsers are highly permissive. If an attacker manages to inject a <script> tag into your page (a Cross-Site Scripting or XSS attack), the browser will happily execute it.

A CSP completely neuters XSS attacks. If you configure your CSP to only allow scripts from https://yourdomain.com, and an attacker injects a script pointing to https://evil-hacker.com, the browser will flat-out refuse to load the attacker's script and throw an error in the console.

---

3. CSP Header Directives — Complete Reference

A CSP is composed of "directives" separated by semicolons. Here are the core directives you need to know in 2026:

Directive	What It Controls	Example Value	Notes
default-src	Fallback for all other directives	'self'	Always start by setting this to 'self'.
script-src	JavaScript execution	'self' https://js.stripe.com	The most critical directive for XSS prevention.
style-src	CSS stylesheets	'self' 'unsafe-inline'	Inline styles are common; carefully consider hashes if possible.
connect-src	Fetch, XHR, WebSockets	https://api.mybackend.com	Where your frontend can send data.
img-src	Images and favicons	'self' data: https://cdn.com	Allow data: for inline base64 images if needed.
frame-ancestors	Who can iframe your site	'none'	Replaces X-Frame-Options.
report-uri	Where to send violation logs	https://api.site.com/csp-log	Deprecated in CSP Level 3 (replaced by report-to), but still widely supported.

---

4. How to Build a CSP Header Step by Step

Here is the bulletproof, production-ready methodology for deploying a CSP without breaking your site.

Step 1 — Start With Report-Only Mode

Never use Content-Security-Policy initially. Always use: Content-Security-Policy-Report-Only

This tells the browser: "Pretend this policy is enforced. If something violates it, don't block it, just send a JSON report to my server."

Step 2 — Identify Your Script and Style Sources

Open your site and look at the Network tab. What external services do you rely on?

• Analytics (Google Analytics, Plausible)
• Payments (Stripe, PayPal)
• Fonts (Google Fonts, Typekit)
• CDNs (Cloudflare, AWS CloudFront)

Step 3 — Generate the Header With a Tool

Manually typing CSP syntax is error-prone. Use our CSP Builder tool to select your directives and generate the string.

A good baseline for a modern web app looks like this:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://js.stripe.com https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.stripe.com; img-src 'self' data:; frame-ancestors 'none'; report-uri /api/csp-report;

Step 4 — Test Without Breaking Anything

Deploy the Report-Only header to production. Watch your /api/csp-report endpoint. You will discover third-party scripts you completely forgot about. Update your policy to include them.

Step 5 — Switch From Report-Only to Enforced

Once you go 48 hours without seeing any legitimate violations in your report logs, rename the header from Content-Security-Policy-Report-Only to Content-Security-Policy.

Congratulations, your site is now armored against XSS.

---

5. Nonce-Based CSP — The Safest Approach in 2026

In the past, developers used domain whitelisting (e.g., script-src https://cdn.example.com). However, if an attacker finds an open JSONP endpoint on that CDN, they can bypass the whitelist.

The 2026 standard is Strict CSP using Nonces. A nonce is a randomly generated string created by your server on every page load.

Server generates the header:

Content-Security-Policy: script-src 'nonce-rAnd0m123' 'strict-dynamic';

Server renders the HTML:

<script nonce="rAnd0m123" src="/main.js"></script>

Because the attacker doesn't know the random nonce for the current page load, they cannot inject a <script> tag that the browser will execute. The 'strict-dynamic' keyword tells modern browsers to allow scripts loaded by the nonce-approved script, making it incredibly easy to use with modern frameworks like Next.js and Nuxt.

---

6. Common CSP Mistakes That Break Sites

• Forgetting data: in img-src: Many bundlers (like Webpack or Vite) convert small images into base64 data:image/... URIs. If you don't allow data: in img-src, these images will break.
• Blocking Google Fonts: Google Fonts requires style-src https://fonts.googleapis.com AND font-src https://fonts.gstatic.com.
• Using unsafe-inline for scripts: It disables the primary security benefit of the CSP. Use nonces instead.
• Deploying CSP via Meta Tag for SPAs: If you use a <meta> tag CSP in a React/Vue Single Page Application, you cannot use the report-uri or frame-ancestors directives.

---

7. CSP vs X-Frame-Options vs HSTS — When to Use Which

Security headers are a team effort. Here is how they interact:

Header	Primary Purpose	Status in 2026
Content-Security-Policy	Prevents XSS and data exfiltration	Critical Standard
X-Frame-Options	Prevents Clickjacking (iframes)	Obsolete (Use CSP frame-ancestors)
Strict-Transport-Security (HSTS)	Forces HTTPS	Critical Standard
Permissions-Policy	Blocks browser features (Camera, Mic)	Recommended Standard

---

Frequently Asked Questions

Q: Do I need a CSP if I use a modern framework like React or Angular? A: Yes. While frameworks escape text by default (preventing basic XSS), vulnerabilities in third-party npm packages, use of dangerouslySetInnerHTML, or bypasses in the framework itself can still lead to XSS. Defense in depth is required.

Q: Can I use both Report-Only and Enforced CSP at the same time? A: Yes! You can send an enforced policy for your core rules, and a report-only policy for new rules you are testing. The browser will process both.

---

Build and validate your policy safely. Use our free CSP Builder to generate complex policies, and combine it with our HSTS Generator and Robots.txt Toolkit to lock down your site infrastructure →

---

External Sources

• MDN Web Docs: Content Security Policy (CSP)
• Google Web.dev: Strict CSP
• W3C Content Security Policy Level 3

---

Abu Sufyan · Full-stack developer · Founder of WebToolkit Pro Github

Last updated: June 2026