Content-Security-Policy

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

Google Maps JavaScript API is one of those integrations that looks simple until CSP gets involved. Then you add one <script> tag, refresh, and your console turns into a wall of violations. The hard part is that Google Maps does not just load one script. It pulls in additional scripts, images, styles, XHR/fetch requests, and sometimes fonts from multiple Google domains. If your policy is strict — and it should be — you need to allow the right sources without opening the door too wide. ...

I’ve had to fix this exact problem more than once: a site adds KaTeX for math rendering, everything works locally, then production CSP turns it into a pile of console errors. KaTeX itself is usually not the hard part. The hard part is fitting it into a CSP that already has analytics, consent tooling, nonces, and a bunch of inherited decisions nobody wants to touch. Here’s a real-world style case study based on a production-shaped policy, using the kind of CSP you actually see on a live site. ...

CSP for Deck.gl: A Real-World Before and After Deck.gl is one of those libraries that looks straightforward until you lock down your Content Security Policy and the map quietly dies in production. I’ve seen this happen more than once: everything works locally, the app gets deployed behind a stricter CSP, and suddenly you’re staring at a blank canvas, a couple of cryptic console errors, and a team chat full of “did maps just break?” ...

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

I hit this problem on a React app using Grommet and grommet-icons: the app looked fine locally, then icons mysteriously disappeared once I tightened the Content Security Policy. No console errors about JavaScript failures. No broken imports. Just empty spaces where icons should be. That kind of bug is annoying because it looks like a UI issue, but the root cause is security policy. Here’s the real-world version of what happened, what broke, and the CSP changes that fixed it without throwing the policy in the trash. ...

Carbon gives teams a solid design system, but it does not magically solve CSP. I’ve seen plenty of Carbon-based apps ship with a polished UI and a deeply unserious security header: default-src *, script-src 'unsafe-inline', or no CSP at all because “the charts broke.” That tradeoff usually happens when a team mixes Carbon with analytics, consent tooling, a React build pipeline, and a few “temporary” inline scripts that somehow survive for two years. ...

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