Javascript

C3.js is handy because it gets you from raw data to charts fast. It’s also one of those libraries that tends to expose every weak spot in a sloppy Content Security Policy. I’ve seen teams lock down CSP, deploy C3.js, and then spend an afternoon wondering why the chart container stays blank while the console screams about blocked scripts or styles. Usually the breakage isn’t C3 itself. It’s the mix of D3, inline config, CDN habits, and CSS assumptions. ...

I’ve seen this exact failure pattern a few times: a team adds Mermaid to docs or an internal dashboard, the diagrams look great locally, then production CSP quietly wrecks everything. The symptoms are boring but expensive: diagrams don’t render initialization throws console errors someone “fixes” it by adding 'unsafe-inline' or weakening script-src now the page works, but the policy got worse Mermaid is a perfect example of where frontend convenience collides with a real CSP. If you run a site with a strict policy, you can’t just paste the snippet from a README and hope for the best. ...

DartPad-style apps are a weird CSP target. You’re not just serving a normal frontend. You’ve got inline bootstrapping code, dynamic script loading, iframes, workers, API calls, maybe WebSockets, and often some analytics or consent tooling bolted on top. That combination is exactly where people give up and slap unsafe-inline and unsafe-eval into production. I’ve done that under deadline pressure. I’ve regretted it every time. If you’re building something like DartPad, the goal is to allow the platform features you actually need without turning CSP into decorative security theater. ...

Highcharts is one of those libraries that usually works fine until you turn on a real Content Security Policy. Then the fun starts: tooltips stop rendering, exports break, inline styles get blocked, and you end up staring at DevTools wondering which directive is yelling at you this time. I’ve had better results treating Highcharts like any other third-party JavaScript dependency: start with a strict CSP, load only what you need, and loosen the policy only when you can prove why. ...

A lot of CSP advice sounds clean on paper and falls apart the second you add the usual site accoutrement: analytics, tag managers, cookie consent, forms, embeds, and one “temporary” inline script that survives for two years. That’s why CSP work gets messy on real sites. I’m going to use a real-world style policy based on the header observed on headertest.com and walk through what a developer-facing site like csp-examples would look like before and after tightening it up. ...

Monaco Editor is one of those libraries that looks simple until you deploy it behind a strict Content Security Policy. Then the fun starts: web workers, dynamic loading, styles, fonts, and sometimes blob URLs depending on how you bundle it. If you’re embedding Monaco on a site with a real CSP, you need to decide two things early: Are you self-hosting Monaco assets or pulling them from a CDN? Are Monaco workers loaded as separate files, or through blob: URLs? That choice changes your policy a lot. ...

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