Csp

A lot of CSP advice sounds clean on paper and falls apart the second you add the usual site accoutrement: analytics, tag managers, cookie consent, forms, embeds, and one “temporary” inline script that survives for two years. That’s why CSP work gets messy on real sites. I’m going to use a real-world style policy based on the header observed on headertest.com and walk through what a developer-facing site like csp-examples would look like before and after tightening it up. ...

Visx is one of those rare charting libraries I actually like using. It gives you low-level control, stays close to SVG, and doesn’t drag in a giant black-box runtime. From a CSP perspective, that’s good news. The short version: Visx itself is usually CSP-friendly. It renders React components into SVG and doesn’t need eval, inline scripts, or weird dynamic code loading. Most CSP breakage around Visx comes from the app around it: tooltips, inline styles, custom HTML labels, analytics, and dev tooling. ...

I’ve had to fix this exact problem more than once: design wants an InVision prototype embedded on a marketing page or internal docs site, everything works locally, then production CSP blocks it hard. The usual bad fix is “just allow everything from https: in frame-src and script-src.” That gets the demo unblocked and quietly wrecks the value of CSP. A better fix is boring and precise: figure out exactly what the embed needs, add the minimum policy changes, and verify you didn’t loosen unrelated directives. ...

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

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

Ariakit is a headless UI toolkit, which is good news for CSP. It doesn’t force a CSS-in-JS runtime, it doesn’t need eval, and it generally stays out of your way. That means you can run a pretty strict Content Security Policy without fighting your component library. The tricky part usually isn’t Ariakit itself. It’s your app shell, analytics, consent tools, inline bootstrapping scripts, and whatever your framework injects during hydration. ...

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