Content-Security-Policy

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

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

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

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

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

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