Frontend

Bandcamp embeds look simple right up until your CSP starts blocking them. You paste the iframe, refresh, and get a blank box or a console full of violations. I’ve seen this pattern a lot: teams lock down CSP correctly, then third-party embeds get boladted on later and nobody updates the policy with any care. The result is usually one of two bad outcomes: the embed breaks, or somebody “fixes” it by allowing way too much. Bandcamp is pretty tame compared to ad tech or social widgets, but there are still a few easy mistakes that keep showing up. Here’s what tends to go wrong, and how I’d fix it without turning your CSP into allow basically everything. ...

I’ve run into this exact problem a few times: a team tightens Content Security Policy, ships it to production, and suddenly half the icons vanish. Not SVG logos. Not a giant component library. Tiny CSS.gg icons. They look harmless because CSS.gg is “just CSS”. That’s exactly why they get people into trouble. CSS-based icon sets often depend on inline styles, pseudo-elements, CSS variables, or external stylesheets loaded from a CDN. All of those can collide with a strict style-src. ...

If you’re building a Foundation site, CSP usually gets messy in two places fast: JavaScript plugins and inline styles. Foundation itself isn’t uniquely hard to secure, but the usual stack around it—jQuery, what-input, CDN assets, analytics, consent banners—turns a clean policy into a pile of exceptions if you’re not careful. This guide is the version I wish I had when tightening CSP on a real Foundation app: minimal theory, lots of working policies. ...

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

CSS-in-JS is great right up until you try to lock down style-src. That’s where the friction starts. Many CSS-in-JS libraries inject <style> tags at runtime, and CSP treats those as inline styles. If your policy is strict, those styles get blocked unless you loosen style-src or add a nonce. I’ve seen teams spend weeks tightening script-src only to quietly leave style-src 'unsafe-inline' in place because Emotion, styled-components, JSS, or a legacy UI kit needed it. That usually happens because CSS-in-JS was adopted for developer experience, while CSP got added later under security pressure. ...

Theme UI is great until you turn on a real Content Security Policy and half your styling disappears. I’ve hit this a few times with React apps that looked perfectly fine in development, then blew up the moment a stricter CSP landed in production. Theme UI makes styling ergonomic, but it also leans on runtime style injection. That’s exactly where people get tripped up. If you’re locking down a Theme UI app, the biggest mistakes usually come from treating CSP like a static checklist instead of something that has to match how your app actually renders styles and scripts. ...

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