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?” ...
CodeMirror 6 is much friendlier to Content Security Policy than a lot of frontend tooling. That said, I still see people break their CSP the moment they add an editor, especially when they cargo-cult old CodeMirror 5 examples or loosen the policy until the errors disappear. That’s the wrong move. If you’re using CodeMirror 6, you can usually keep a pretty tight CSP. Most of the pain comes from a few repeat mistakes: allowing the wrong directives, mixing up CodeMirror 5 and 6 behavior, or forgetting that your app around the editor has its own CSP needs. ...
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. ...
I’ve seen this exact problem show up on developer docs sites more than once: syntax highlighting works great in local dev, then you tighten CSP in production and Prism.js suddenly becomes the thing breaking your code examples. That’s annoying on any site. On a developer-facing site, it’s worse. Broken code blocks make the whole site feel untrustworthy. Here’s a real-world case study for csp-examples, based on a common setup: a docs or blog site using Prism.js for syntax highlighting, plus analytics and consent tooling, with a production CSP that already looks pretty serious. ...
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. ...
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. ...
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. ...
MathJax is one of those libraries that looks harmless until you lock down your CSP and everything explodes. You ship a clean policy, reload the page, and suddenly your equations stay as raw TeX, inline styles get blocked, fonts don’t load, and the console turns into a crime scene. I’ve seen teams blame MathJax, blame CSP, then quietly add 'unsafe-inline' everywhere just to make the pain stop. That works, but it’s a bad trade. ...
I’ve seen this pattern a lot: a team adds MapLibre GL JS to an otherwise locked-down site, ships to staging, and the map quietly explodes under Content Security Policy. No tiles. No markers. Maybe the page itself works, but the console fills up with CSP errors about workers, styles, images, and network requests. Then somebody reaches for 'unsafe-inline' or loosens connect-src to https: and calls it a day. That’s how good CSPs 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.” ...