Web-Security

Wistia Channels are easy to drop into a page. Getting them past a strict Content Security Policy is the part that usually wastes an afternoon. If you embed a Wistia Channel and your CSP is even moderately locked down, you’ll usually hit one of these: the channel frame doesn’t render JavaScript inside the embed gets blocked thumbnails or poster images disappear analytics or websocket connections fail custom styling breaks This guide is the practical version: what to allow, why, and copy-paste policies you can start with. ...

If you’ve ever dropped a Mixcloud embed into a page and watched it fail under a strict Content Security Policy, you already know the pattern: the iframe looks harmless, but CSP doesn’t care about harmless. It cares about explicit allowlists. I’ve run into this a lot on sites that already have a decent CSP and then bolt on third-party media later. Everything is locked down, then one product request lands: “Can we embed this Mixcloud show by Friday?” ...

Picnic CSS is refreshingly simple. Drop in one stylesheet, get decent defaults, and move on with your life. That simplicity also makes CSP easier than with heavier UI frameworks that drag in fonts, inline scripts, runtime style injection, and mystery third-party assets. If you’re using Picnic CSS, you can usually get to a pretty strict Content Security Policy without much pain. What Picnic CSS changes for CSP Picnic CSS is just CSS. No JavaScript runtime. No client-side style injection. No dependency on external fonts unless you add them yourself. ...

Spectre.css is easy to secure with CSP because it’s just CSS. No JavaScript runtime, no weird asset loader, no inline script requirements. That’s the good part. The catch is everything around it: icon fonts, third-party CDNs, analytics, consent banners, inline styles from old templates, and framework glue code you forgot was there. This guide is the practical version. Copy-paste policies first, then adjust for your setup. What Spectre.css needs from CSP By itself, Spectre.css usually needs: ...

kepler.gl is one of those libraries that looks simple from the outside and then quietly pulls in a lot of browser features once you ship it: Web Workers, WebGL, map tiles, fonts, API calls, and often third-party basemaps. That makes Content Security Policy trickier than a plain React app. If you lock CSP down too early, kepler.gl usually breaks in non-obvious ways: blank map canvas workers failing to start tiles not loading icons or fonts disappearing map style JSON fetching but not rendering This guide is the practical version: what to allow, what usually breaks, and copy-paste CSP examples you can start from. ...

If you want to drop a Deezer player into a page without punching unnecessary holes in your Content Security Policy, you’ve got a couple of decent options and one bad habit to avoid. The bad habit is the usual one: something breaks, you sprinkle domains across default-src, maybe throw in https: for good measure, and call it done. That works right up until your CSP stops being a security control and becomes decorative wallpaper. ...

I’ve seen this exact problem show up on developer docs sites more than once: syntax highlighting works great in local dev, then you tighten CSP in production and Prism.js suddenly becomes the thing breaking your code examples. That’s annoying on any site. On a developer-facing site, it’s worse. Broken code blocks make the whole site feel untrustworthy. Here’s a real-world case study for csp-examples, based on a common setup: a docs or blog site using Prism.js for syntax highlighting, plus analytics and consent tooling, with a production CSP that already looks pretty serious. ...

shadcn/ui gives you a weird CSP problem compared to most component libraries: it is not really a library in the classic sense. You copy components into your app, own the code, and then your CSP story becomes your problem. That is good for flexibility, but it also means there is no single “shadcn/ui CSP policy.” The right policy depends on how you render styles, whether you use theme scripts, whether you pull in analytics, and whether your app is static, SSR, or edge-rendered. ...

JSFiddle embeds look harmless until your CSP blocks them or, worse, you punch a giant hole in your policy just to make one iframe work. I’ve seen teams “fix” this by slapping frame-src * or default-src https: into production. That works, but it also guts the point of having CSP in the first place. If you only need to embed JSFiddle, you should allow exactly JSFiddle and nothing else. What a JSFiddle embed actually needs A typical JSFiddle embed is just an iframe: ...

Teams love dropping Loom videos into internal portals, onboarding hubs, help centers, and customer dashboards. Security teams usually hate how fast those embeds spread. I’ve seen this pattern a lot: a portal starts with one harmless embedded video, then picks up analytics, a consent banner, a chat widget, and a couple of “temporary” inline scripts that never go away. The CSP ends up either too loose to matter or so strict that Loom breaks in production. ...