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?” ...
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. ...
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. ...
I’ve seen the same pattern a few times with Three.js projects: the 3D demo works, the product team loves it, then someone turns on a real Content Security Policy and half the scene stops loading. The root problem usually is not Three.js itself. It’s everything wrapped around it: inline bootstrapping scripts, shader loading, texture CDNs, analytics, WebSocket dev tooling, model fetches, and a build pipeline that quietly assumes permissive browser behavior. ...
Nivo is usually a pretty easy fit for a strict Content Security Policy. That’s the good news. The catch is that teams often blame the charting library when the real CSP breakage comes from everything around it: analytics, consent banners, custom fonts, exported images, server-side rendering, or a dev setup that quietly relies on unsafe-eval. If you’re adding Nivo charts to a production app and want a sane CSP, here’s how I’d approach it. ...
Vanilla Extract is one of the easier styling tools to live with under a strict Content Security Policy. That’s the good news. The reason is simple: Vanilla Extract compiles styles to real CSS files at build time. No runtime style injection, no CSS-in-JS engine pushing <style> tags into the DOM on page load, no constant fight with style-src nonces. If you care about CSP, that’s already a huge win. Still, “works better with CSP” is not the same thing as “done.” Teams often ship a decent script-src and then quietly leave style-src 'unsafe-inline' hanging around forever because some analytics tool, consent manager, or framework edge case made it convenient. ...
Chart.js v4 is one of the easier charting libraries to run under a strict Content Security Policy. That’s the good news. The less fun part: “easier” does not mean “automatic.” The moment you mix Chart.js with inline bootstrapping code, third-party plugins, CDN delivery, tag managers, or framework hydration tricks, your policy gets messy fast. I’ve had to clean this up more than once, and the pattern is always the same: the chart library itself is usually fine, but the surrounding app code quietly punches holes in CSP. ...
A lot of CSP breakage looks random until you hit icons. Text loads. JavaScript loads. Layout mostly works. Then half the UI shows empty squares, missing chevrons, or buttons with no visual affordance at all. I’ve seen teams burn hours blaming CSS pipelines when the real problem was much simpler: the icon delivery method didn’t match the site’s Content Security Policy. This case study is about that exact problem with Evergreen icons on a production-style setup. ...
Highlight.js is usually easy to lock down with Content Security Policy. The core library does not need eval, it does not need inline event handlers, and it works fine under a strict policy if you load it like a normal script. The place where people get sloppy is theming. They drop in inline <style> blocks, use broad CDN allowlists, or keep style-src 'unsafe-inline' around because syntax highlighting “needs it”. It doesn’t. ...
Water.css is the kind of CSS framework I like for security work: tiny, boring, and mostly predictable. That matters for CSP because every extra build step, inline style hack, or third-party asset is another thing you need to allow. If you’re using Water.css, your CSP can usually stay tight. Most setups only need to allow your own origin for styles, or a single CDN if you’re loading it remotely. What Water.css changes in CSP Water.css is just a stylesheet. In the normal case, CSP impact is limited to: ...