Headers

Mux is easy to drop into a page. Getting the CSP right is the part that usually wastes time. The main problem: “Mux embed” can mean a few different things: a plain <iframe> a custom player using Mux-hosted video a player library that pulls thumbnails, HLS manifests, segments, captions, and telemetry a setup mixed into an existing CSP that already has analytics, consent tools, and nonce-based scripts I’ve had to debug all of these, and the failure mode is always the same: the video UI renders, then playback, poster images, subtitles, or analytics quietly break because one directive is missing. ...

If you’re building a Go playground-style app, CSP gets weird fast. A regular Go web app might serve a few static JS files and call it a day. A playground usually does more: runs user code or sends it to a backend sandbox opens WebSocket connections for logs or interactive output injects bootstrapping data into the page embeds editors like Monaco or CodeMirror uses inline scripts because templating makes it convenient That combination is exactly where sloppy CSP setups happen. ...

Self-hosting Google Fonts is supposed to simplify CSP. No fonts.googleapis.com, no fonts.gstatic.com, fewer third parties, cleaner policy. That’s the theory. In practice, I keep seeing teams self-host fonts and still break rendering, keep unsafe CSP rules they no longer need, or ship policies that are way broader than necessary. The annoying part is that the app usually “works” until someone tightens CSP in production and suddenly every heading falls back to Arial. ...

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

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

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

Nivo is usually a pretty easy fit for a strict Content Security Policy. That’s the good news. The catch is that teams often blame the charting library when the real CSP breakage comes from everything around it: analytics, consent banners, custom fonts, exported images, server-side rendering, or a dev setup that quietly relies on unsafe-eval. If you’re adding Nivo charts to a production app and want a sane CSP, here’s how I’d approach it. ...

If you want to embed Eraser in a site with a sane Content Security Policy, you have a few choices. None of them are perfect. The right one depends on whether you care more about tight isolation, easy maintenance, or preserving a very strict policy posture. I’ve had to make this tradeoff on production apps, and the pattern is always the same: the embed itself is easy, the CSP around it is where the mess starts. ...