Csp

ApexCharts is one of those libraries that looks harmless until you turn on a strict Content Security Policy and parts of your charts suddenly stop rendering. I’ve hit this a few times in dashboards where everything worked fine locally, then failed in staging because CSP blocked inline styles or scripts. ApexCharts itself is pretty friendly compared to some older charting libraries, but you still need to account for how it injects styles and how your app loads it. ...

YouTube embeds look simple until CSP gets involved. The usual failure mode goes like this: you paste an <iframe> embed, add autoplay=1, ship a strict policy, and suddenly the video is blank or blocked in the console. Then someone “fixes” it by throwing https: into frame-src or loosening half the policy. That works, but it’s lazy and expensive from a security standpoint. Here’s the version I’d actually ship for a developer-facing site. ...

Milligram is tiny, clean, and boring in the best possible way. That makes it a great fit for a strict Content Security Policy. If your CSS framework is just a stylesheet and not a JavaScript carnival, you can usually lock things down harder than most teams think. I’ve seen the opposite happen in production: a simple site starts with Milligram, then marketing adds Google Tag Manager, analytics, a consent banner, maybe a form embed, and suddenly the CSP turns into a landfill of wildcard domains and unsafe-inline. ...

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