Content-Security-Policy

If you’re tuning CSS in production, you’ll usually end up doing two things: minifying with cssnano removing unused selectors with a purge step Those are build-time optimizations, so people assume CSP has nothing to do with them. That assumption bites later. CSP does not care that your CSS was generated by PostCSS, cssnano, Tailwind, PurgeCSS, or a custom pipeline. CSP only sees what the browser sees: where styles came from, whether they were inline, and whether some script injected them at runtime. ...

Spotify embeds are simple until your CSP blocks them. You paste the iframe, reload the page, and get a blank box or a browser console full of Refused to frame errors. I’ve hit this enough times that I keep a tiny checklist for it. This guide is that checklist, with policies you can copy-paste. If you only need the shortest possible answer: Spotify embeds need frame-src https://open.spotify.com If your page itself is allowed to be embedded nowhere, keep frame-ancestors 'none' You usually do not need to loosen script-src for a plain Spotify iframe embed If your CSP is based on default-src 'self', you must explicitly allow Spotify in frame-src The basic Spotify embed HTML A typical Spotify embed looks like this: ...

Cookie consent banners are one of the easiest ways to blow up an otherwise clean Content Security Policy. I’ve seen teams lock down script-src, remove inline JS, add nonces everywhere, and then ship a consent platform that quietly needs half a dozen extra hosts, a stylesheet exception, iframe support, and a callback script jammed into the page head. Suddenly the CSP report inbox catches fire. This guide is the practical version: what to allow, where teams usually get it wrong, and copy-paste CSP examples for OneTrust and Osano. ...

Facebook video embeds are one of those things that look trivial until CSP starts blocking them. You paste Facebook’s embed code, reload, and suddenly your console is full of Refused to frame or Refused to load the script errors. The fix is usually small, but the exact directives matter. If you loosen the wrong thing, you end up with a policy that “works” and quietly stops protecting anything useful. Here’s the practical reference I wish more teams had handy. ...

Google Maps is one of those integrations that looks trivial right up until CSP starts blocking half of it. I’ve seen this play out a few times: the site already has a decent policy, someone drops in a Maps embed or the JavaScript API, and suddenly the console fills with CSP errors. The quick fix is usually script-src https://maps.googleapis.com 'unsafe-inline' plus a couple of random domains copied from Stack Overflow. That works, but it also turns a decent policy into a mushy one. ...

Google Pay is one of those integrations that looks tiny in code and then immediately punches a hole through your CSP if you guessed the source list wrong. You add a payment button, load the Google Pay JavaScript, open a payment sheet, and suddenly the browser starts yelling about blocked scripts, frames, or network connections. I’ve dealt with this enough times that I now treat payment integrations as CSP work first and feature work second. ...

Trust badges and review widgets are classic CSP troublemakers. They look harmless: a tiny badge, a star rating, maybe a “verified reviews” block in the footer. Then you add one script and suddenly you need script-src, frame-src, img-src, style-src, and connect-src exceptions across half the internet. I’ve cleaned this up on enough production sites to have a strong opinion: treat every badge or review widget like a third-party app, not a decoration. ...

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. ...