Frontend

I’ve had to fix this exact problem more than once: a site adds KaTeX for math rendering, everything works locally, then production CSP turns it into a pile of console errors. KaTeX itself is usually not the hard part. The hard part is fitting it into a CSP that already has analytics, consent tooling, nonces, and a bunch of inherited decisions nobody wants to touch. Here’s a real-world style case study based on a production-shaped policy, using the kind of CSP you actually see on a live site. ...

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

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

Carbon gives teams a solid design system, but it does not magically solve CSP. I’ve seen plenty of Carbon-based apps ship with a polished UI and a deeply unserious security header: default-src *, script-src 'unsafe-inline', or no CSP at all because “the charts broke.” That tradeoff usually happens when a team mixes Carbon with analytics, consent tooling, a React build pipeline, and a few “temporary” inline scripts that somehow survive for two years. ...

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

Spectre.css is easy to secure with CSP because it’s just CSS. No JavaScript runtime, no weird asset loader, no inline script requirements. That’s the good part. The catch is everything around it: icon fonts, third-party CDNs, analytics, consent banners, inline styles from old templates, and framework glue code you forgot was there. This guide is the practical version. Copy-paste policies first, then adjust for your setup. What Spectre.css needs from CSP By itself, Spectre.css usually 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. ...

Web fonts are one of those things teams barely think about until the site starts flashing invisible text, Lighthouse complains, or CSP suddenly blocks production traffic. I’ve seen this happen a lot: someone tightens Content Security Policy, feels good about shipping a safer header, and then fonts start failing in subtle ways. Not always completely broken. Sometimes they just get slower. And slow fonts are nasty because they hurt rendering, CLS, and perceived quality without looking like an obvious outage. ...

Teams usually treat icons as harmless. They are tiny, static, and easy to ignore in a CSP rollout. Then the first production deploy lands and half the UI loses its glyphs, the marketing tag manager still works, and somebody “fixes” it by adding img-src * data:. I’ve seen this happen more than once. This case study is about a site I’ll call Bytesize Icons: a developer-facing site with a searchable icon catalog, docs pages, a React app shell, analytics, and consent tooling. The goal was simple: lock down CSP without breaking icon rendering. ...