Web-Security

Figma embeds are one of those things that look trivial until your CSP blocks them and you end up staring at a blank iframe. If you’re embedding a Figma file, prototype, or board on your site, the CSP piece is usually small but annoyingly specific. The main directive you need is frame-src. Sometimes you also need to think about child-src, frame-ancestors, and the fact that Figma itself loads its own resources inside the iframe, not in your page context. ...

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

PSPDFKit viewer is one of those libraries that can blow up a strict CSP if you treat it like a plain old script include. PDF rendering, workers, fonts, blobs, WebAssembly, and sometimes remote assets all show up fast. I’ve had the best results by starting with a very tight policy, then opening only what the viewer actually needs in your setup. That matters because PSPDFKit deployments vary a lot: self-hosted assets CDN-hosted assets standalone browser viewer server-backed mode WebSocket features blob/object URLs for document rendering inline bootstrapping code from your app So a working CSP for one app can still fail badly in another. ...

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

Pico.css is refreshingly boring in the best way. Drop in one stylesheet, get decent defaults, move on with your life. That simplicity tricks people into thinking CSP will be simple too. Usually it is — until someone adds a CDN link, a theme switcher, a bit of inline CSS, or a framework that sneaks in runtime style injection. Then your “tiny CSS setup” turns into a pile of CSP violations. ...

Mux is easy to drop into a page. Getting the CSP right is the part that usually wastes time. The main problem: “Mux embed” can mean a few different things: a plain <iframe> a custom player using Mux-hosted video a player library that pulls thumbnails, HLS manifests, segments, captions, and telemetry a setup mixed into an existing CSP that already has analytics, consent tools, and nonce-based scripts I’ve had to debug all of these, and the failure mode is always the same: the video UI renders, then playback, poster images, subtitles, or analytics quietly break because one directive is missing. ...

Google Maps JavaScript API is one of those integrations that looks simple until CSP gets involved. Then you add one <script> tag, refresh, and your console turns into a wall of violations. The hard part is that Google Maps does not just load one script. It pulls in additional scripts, images, styles, XHR/fetch requests, and sometimes fonts from multiple Google domains. If your policy is strict — and it should be — you need to allow the right sources without opening the door too wide. ...

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

If you’re building a Go playground-style app, CSP gets weird fast. A regular Go web app might serve a few static JS files and call it a day. A playground usually does more: runs user code or sends it to a backend sandbox opens WebSocket connections for logs or interactive output injects bootstrapping data into the page embeds editors like Monaco or CodeMirror uses inline scripts because templating makes it convenient That combination is exactly where sloppy CSP setups happen. ...

Self-hosting Google Fonts is supposed to simplify CSP. No fonts.googleapis.com, no fonts.gstatic.com, fewer third parties, cleaner policy. That’s the theory. In practice, I keep seeing teams self-host fonts and still break rendering, keep unsafe CSP rules they no longer need, or ship policies that are way broader than necessary. The annoying part is that the app usually “works” until someone tightens CSP in production and suddenly every heading falls back to Arial. ...