Posts

If you embed Typeform, SurveyMonkey, Google Forms, or similar widgets, CSP gets annoying fast. The failure mode is usually the same: the survey box is blank, the console screams about frame-src or script-src, and someone “fixes” it by throwing https: into half the policy. That works, but it also guts the point of CSP. I’d rather ship a tight policy and open only what the embed actually needs. The common CSP directives for survey embeds For most survey providers, these are the directives that matter: ...

YouTube embeds look simple right up until your Content Security Policy starts blocking half the player. I’ve seen this trip up a lot of teams: the page works fine locally, then production sends a strict CSP header and suddenly the iframe is blank, thumbnails don’t load, or the player API silently fails. The fix usually isn’t “disable CSP.” It’s understanding which directives YouTube actually hits, and keeping the allowlist as tight as possible. ...

LaunchDarkly is one of those tools that looks harmless from a CSP perspective until it quietly breaks in production. The SDK initializes, flags never arrive, and the only clue is a blocked request buried in DevTools. I’ve seen this a lot with frontend teams that already have a decent CSP and assume feature flags are “just another script.” They usually aren’t. LaunchDarkly needs network access for streaming, polling, events, and sometimes bootstrapping behavior that doesn’t fit neatly into a locked-down policy. ...

The hardest part of implementing CSP isn’t understanding the directives — it’s figuring out which domains to whitelist for every third-party service your site uses. Each one needs specific domains in specific directives, and the documentation is scattered across different sites. I’ve spent way too much time hunting down the exact domains for various services. Here’s everything in one place. These are tested, copy-paste ready, and include the domains most people miss. ...

Single Page Applications have a unique relationship with CSP. The development workflow depends on things CSP doesn’t like — eval for HMR, inline styles for CSS-in-JS, dynamic script loading. But in production, SPAs actually benefit enormously from CSP because they’re JavaScript-heavy. Here are configurations that work for each major framework, based on production deployments. React (Vite) Vite is the recommended build tool for new React projects. Development // vite.config.js export default defineConfig({ plugins: [react()], server: { headers: { 'Content-Security-Policy': "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https: blob:; font-src 'self'; connect-src 'self' ws:; frame-ancestors 'none'" } } }); ```text You need `unsafe-eval` for Vite's hot module replacement. You need `ws:` in connect-src for the WebSocket connection Vite uses to push HMR updates. You need `blob:` in img-src because some bundlers use blob URLs for certain assets. These are development-only concessions. In production, you can be much stricter. ### Production Deploy via Nginx or your reverse proxy: location / { add_header Content-Security-Policy “default-src ‘self’; script-src ‘self’; style-src ‘self’ ‘unsafe-inline’; img-src ‘self’ data: https: blob:; font-src ‘self’; connect-src ‘self’ https://api.yoursite.com; frame-ancestors ’none’; base-uri ‘self’” always; try_files $uri $uri/ /index.html; } ...

Tailwind CSS is great right up until you try to lock down your site with a real Content Security Policy. Then the usual “just drop in the CDN script” advice falls apart. If you care about CSP, Tailwind setup choices matter. A lot. Some Tailwind patterns work cleanly with a strict policy. Others push you toward 'unsafe-inline' or 'unsafe-eval', which is exactly the kind of compromise you were probably trying to avoid. ...

Every CMS platform fights CSP in its own way. WordPress injects inline scripts everywhere. Drupal has its own asset management layer. Joomla plugins do whatever they want with no regard for security headers. Here are working CSP configurations for each, based on real deployments I’ve done. These won’t break your site — I’ve tested them. WordPress WordPress is the hardest because of how many things inject inline scripts. The Gutenberg editor, plugins, themes, and WordPress core itself all add JavaScript dynamically. The admin panel is essentially impossible to fully lock down. ...

Deploying a CSP policy without testing first is like deploying a database migration without a backup. It might work. It might take down your entire site. Report-only mode lets you find out what will break before it actually breaks. The browser logs violations but doesn’t block anything. You get all the data, none of the pain. The Report-Only Header It’s literally just a different header name: Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /api/csp-report Same syntax. Same directives. Same evaluation. The only difference: the browser reports violations instead of blocking them. ...

If you’re serious about XSS prevention, nonce-based CSP is the way to go. It’s stronger than hash-based CSP, more maintainable than domain whitelisting, and once you understand the pattern, it’s not that complicated. What Is a Nonce? A nonce (Number Used Once) is a random string generated by your server for each HTTP request. You include it in your CSP script-src directive AND in every <script> tag on the page. Scripts without the correct nonce are blocked. ...