Web-Security

Adobe Fonts is one of those integrations that looks trivial until your CSP starts blocking it in production. You add the embed code, ship a strict policy, and suddenly your typography falls back to system fonts. Or worse, you loosen style-src too much just to get it working and quietly undo a big chunk of your CSP hardening. I’ve had to clean this up more than once. The good news: Adobe Fonts usually needs only a small set of allowances. The bad news: a lot of examples online are either too broad or copy-pasted from unrelated setups. ...

SoundCloud embeds look simple: paste an <iframe>, ship it, done. Then CSP gets involved and the player disappears, the console fills with violations, and somebody “fixes” it by slapping https: into half the policy. That’s the usual failure mode. If you’re embedding SoundCloud on a site with a real Content Security Policy, the trick is to allow exactly what the embed needs and nothing else. Most breakages come from guessing the wrong directive, overusing default-src, or trying to force a third-party widget into a policy designed only for first-party code. ...

goober is tiny, fast, and refreshingly unpretentious. That’s exactly why people like it. But the moment you try to lock down a real app with Content Security Policy, CSS-in-JS stops being a styling choice and starts becoming a security deployment problem. The short version: goober usually injects styles into <style> tags at runtime. CSP cares a lot about that. If your policy is strict, those injected styles can get blocked unless you deliberately allow them. ...

Sass + CSS Modules usually feels boring in the best possible way. You write .module.scss, import it into a component, get locally scoped class names, and move on with your life. Then CSP shows up and breaks your build in ways that are annoyingly indirect. The tricky part is that Sass CSS Modules themselves are not the problem. The problem is how your toolchain delivers the compiled CSS to the browser. Some setups emit static .css files. Others inject <style> tags at runtime. CSP treats those very differently. ...

Embedding Apple Music looks simple right up until your CSP blocks it and leaves you staring at a blank iframe. I’ve hit this a few times on locked-down sites: the page loads fine, your own scripts work, and then the Apple Music player silently fails because frame-src or child-src doesn’t allow Apple’s embed origin. If you’re running a reasonably strict policy, you need to account for the iframe itself and, depending on your setup, any assets or network requests your page makes around it. ...

Twitch embeds look simple right up until CSP gets involved. Then you get a blank box, a console full of errors, and a lot of bad advice telling you to just add *.twitch.tv everywhere and move on. That usually “works,” but it’s sloppy and often still incomplete. If you’re embedding a Twitch stream or chat on a site with a real Content Security Policy, there are a handful of mistakes I see over and over. Most of them come from misunderstanding which side controls what: your page’s CSP controls what your page is allowed to load, while Twitch’s own embed rules control whether Twitch will agree to render inside your page at all. ...

Shipping CSP around video players always sounds easy until the stream is black, the poster never loads, and the console starts yelling about blocked media, workers, and manifests. Mux is a good example. The integration itself is usually straightforward. The CSP work around it is where teams burn time, especially when they start with a tight policy and add Mux live streaming later. I’ve seen this pattern a few times: a team has a clean app with default-src 'self', maybe a nonce-based script-src, and things look great. Then product adds live video. Someone pastes in a Mux player, it works locally, and production immediately blocks half of it. ...

Cotiless had the kind of frontend stack I see all the time: marketing scripts, analytics, consent tooling, a couple of “just paste this snippet” integrations, and a team that wanted security without breaking the site. That’s exactly where CSP gets messy. The goal wasn’t to build the most academic Content Security Policy. The goal was to ship a policy that reduced XSS risk, survived real production traffic, and didn’t turn every release into a blame game between security and frontend. ...

MathJax is one of those libraries that looks harmless until you lock down your CSP and everything explodes. You ship a clean policy, reload the page, and suddenly your equations stay as raw TeX, inline styles get blocked, fonts don’t load, and the console turns into a crime scene. I’ve seen teams blame MathJax, blame CSP, then quietly add 'unsafe-inline' everywhere just to make the pain stop. That works, but it’s a bad trade. ...

I’ve seen this pattern a lot: a team adds MapLibre GL JS to an otherwise locked-down site, ships to staging, and the map quietly explodes under Content Security Policy. No tiles. No markers. Maybe the page itself works, but the console fills up with CSP errors about workers, styles, images, and network requests. Then somebody reaches for 'unsafe-inline' or loosens connect-src to https: and calls it a day. That’s how good CSPs die. ...