Web-Security

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

Teams usually treat icons as harmless. They are tiny, static, and easy to ignore in a CSP rollout. Then the first production deploy lands and half the UI loses its glyphs, the marketing tag manager still works, and somebody “fixes” it by adding img-src * data:. I’ve seen this happen more than once. This case study is about a site I’ll call Bytesize Icons: a developer-facing site with a searchable icon catalog, docs pages, a React app shell, analytics, and consent tooling. The goal was simple: lock down CSP without breaking icon rendering. ...

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

UnoCSS is great until you turn on a strict Content Security Policy and your styling quietly falls apart. That’s the tradeoff with on-demand atomic CSS. UnoCSS can inject styles at runtime, and CSP tends to hate runtime injection unless you explicitly allow it. If you’ve ever tightened style-src and then watched your app render as unstyled HTML, you’ve already met the problem. The short version: if UnoCSS is generating or injecting <style> tags in the browser, you need to account for that in CSP. If you can shift style generation to build time or server render time, life gets much easier. ...

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