Security

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

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

A-Frame is a nice way to get WebXR scenes on the screen fast. You can ship VR or AR in a few tags, sprinkle in components, and call it a day. Then CSP shows up and breaks half the experience. I’ve seen this a lot: the app works locally, works in a relaxed staging setup, then production adds a real Content Security Policy and suddenly textures stop loading, inline components fail, analytics goes dark, and WebSocket features quietly die. ...

D3.js v7 is pretty friendly to Content Security Policy compared to older frontend stacks. It does not need eval, it does not inject mystery scripts, and it mostly sticks to normal DOM APIs. That’s the good news. The bad news is that D3 usually lives inside apps that do all the annoying CSP-breaking stuff around it: inline bootstrapping, dynamic data loading, CSS in <style> blocks, analytics tags, and third-party embeds. So the trick is not “make D3 work.” The trick is “make D3 work without punching a giant hole in your policy.” ...

Twind is great when you want Tailwind-style utilities without a build step. The CSP story is where things get annoying. The problem is simple: Twind often injects CSS at runtime using a <style> tag. CSP hates that unless you explicitly allow it. If you try to run Twind under a strict policy without planning for style injection, your app looks broken fast. This guide is the practical version: what breaks, what policy you need, and the least-painful ways to make Twind work. ...

Ghost embeds are easy to drop into a page and easy to forget from a CSP perspective. That’s where people get burned: the embed works in development, then production CSP blocks it, or worse, someone loosens the policy with script-src * and calls it done. Don’t do that. If you’re embedding Ghost content, membership widgets, or Portal-related UI on your site, you need to explicitly allow the right sources and keep the policy tight everywhere else. The good news is Ghost’s embed surface is pretty manageable if you approach it methodically. ...

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