Web-Security

Teams love design systems because they make UI feel consistent. Security teams usually get handed the bill later. That’s exactly where CSP gets painful in a Gestalt-style frontend: lots of reusable components, analytics hooks, consent tooling, embedded assets, and a build pipeline that mixes app code with third-party scripts. If you’re working on a Pinterest-like stack using Gestalt components, you can’t treat Content Security Policy as a checkbox. You need a policy that survives real product code. ...

Plotly.js is great until you put a real Content Security Policy in front of it. I’ve seen this go the same way a bunch of times: charts work fine in local dev, someone adds a decent CSP in staging, and suddenly the graph is blank, console errors pile up, and the quick “fix” is to throw 'unsafe-inline' and 'unsafe-eval' into the policy. That usually gets the chart rendering again, but it also guts the point of having CSP. ...

Reddit embeds look simple until your CSP starts blocking them. I’ve hit this a few times: product wants a Reddit post embedded on a marketing page, security wants a tight policy, and suddenly you’re trying to figure out whether you need frame-src, script-src, connect-src, or all three. The answer depends on how you embed Reddit, and that choice has real security and maintenance tradeoffs. If you’re building for a developer audience, the biggest mistake is treating “support Reddit embeds” as one CSP change. It’s not. There are a few patterns, and each one expands your policy in different ways. ...

Leaflet looks simple until you lock down your site with Content Security Policy. Then the map goes blank, markers disappear, plugin styles break, and you end up staring at DevTools wondering why a harmless map library suddenly needs half the internet. I’ve hit this enough times that I treat Leaflet as a CSP integration task, not just a UI widget. The good news: most failures come from a handful of repeat mistakes. ...

Instagram embeds are one of those things that look simple until CSP gets involved. You paste the embed code, reload the page, and suddenly the post is blank, the console is yelling about blocked frames or scripts, and someone suggests adding https: to half your policy. That usually “works,” but it also wrecks the point of having CSP in the first place. If you want Instagram embeds and a CSP that still means something, you need to decide which tradeoff you’re willing to accept. ...

Recharts is usually one of the easier charting libraries to live with under Content Security Policy. That’s the good news. The bad news: teams still break dashboards with CSP all the time, usually because they copy a broad policy from somewhere else, tighten it blindly, or blame Recharts for behavior caused by their own app shell, analytics, or CSS-in-JS stack. If you’re running Recharts in a React app, most CSP issues come from the environment around the charts, not the chart library itself. Recharts renders SVG. That’s a lot friendlier than libraries that depend on eval, dynamic code generation, or canvas hacks. Still, there are a few predictable ways to mess it up. ...

Remix Icon is easy to drop into a project, which is exactly why people ship it with a sloppy CSP. I’ve seen this a lot: someone adds the Remix Icon CDN snippet, the icons don’t render, they get a wall of CSP errors, and the “fix” becomes style-src 'unsafe-inline' plus a couple of random hostnames copied from the console. That works, but it’s the kind of fix that quietly makes the policy worse every time the app changes. ...

Bulma is one of the easier CSS frameworks to secure with Content Security Policy. That’s mostly because Bulma itself is just CSS. No bundled JavaScript, no weird runtime code generation, no framework magic that sneaks in inline scripts behind your back. That said, real Bulma sites rarely stay “just CSS” for long. You add a navbar burger toggle, a modal, analytics, a consent banner, maybe a form widget, and suddenly your clean CSP turns into a pile of exceptions. ...

Turret CSS is just CSS, so on paper CSP should be easy: allow your stylesheet, block the weird stuff, move on. In practice, teams still break production layouts with CSP all the time. I’ve seen the same pattern over and over: someone tightens style-src, the app ships, and suddenly Turret CSS “doesn’t work.” Usually Turret isn’t the problem. The policy is. More specifically, the policy was written with JavaScript in mind and nobody checked how styles are actually loaded, injected, or modified across the app. ...

If you’ve ever dropped a Vimeo embed onto a page and then wired up the Vimeo Player API, you’ve probably hit the classic wall: the iframe renders, but the API fails in weird ways, or the iframe is blocked entirely by CSP. This happens a lot because Vimeo embeds are one of those features that cross several CSP directives at once. You’re not just allowing a script. You’re allowing a framed document, cross-origin messaging, and sometimes extra assets depending on how you load the player. ...