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. ...
If you use Aragon icons and your CSP is even slightly off, the breakage is usually annoying, subtle, and easy to misdiagnose. You see missing icons, blank squares, CSP console noise, or everything works locally but fails in production. I’ve hit this enough times to have strong opinions about it: most CSP problems around icon libraries come from guessing which directive applies. People tweak default-src, maybe throw in img-src data:, and hope for the best. That’s not how CSP works. ...
Teams usually discover CSP problems with Linaria the annoying way: everything works in development, then production gets a stricter policy and styles start disappearing. I’ve seen this happen when a team moves from a relaxed policy to something closer to a real production header, like the one headertest.com sends: content-security-policy: default-src 'self' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com; script-src 'self' 'nonce-MjgzMGM0NjctNzg4MS00NTNiLThkN2UtNjY3N2VmMTRlOGUy' 'strict-dynamic' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com; style-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://*.cookiebot.com https://consent.cookiebot.com; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.headertest.com https://tallycdn.com https://or.headertest.com wss://or.headertest.com https://*.google-analytics.com https://*.googletagmanager.com https://*.cookiebot.com; frame-src 'self' https://consentcdn.cookiebot.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none' That header is realistic because it shows the usual compromise: strong script controls, but style-src 'unsafe-inline' left behind because CSS tooling got messy. ...
PDF.js is one of those libraries that looks simple until CSP gets involved. You drop in the viewer, load a PDF, and everything works locally. Then you turn on a real Content Security Policy and suddenly the worker fails, fonts disappear, images stop rendering, or the whole viewer goes blank with a useless console error. I’ve hit this a few times. The pattern is usually the same: people start with a generic CSP, then keep adding exceptions until the app works again. That usually ends with unsafe-inline, unsafe-eval, and a policy that technically exists but doesn’t really protect anything. ...