Web-Security

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

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