Headers

Bunny Fonts is one of the easier font providers to support in Content Security Policy, mostly because the setup is simple and the domains are predictable. If you just want the working policy, here it is: Content-Security-Policy: default-src 'self'; style-src 'self' https://fonts.bunny.net; font-src 'self' https://fonts.bunny.net; img-src 'self' data:; script-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; That covers the common case where your page loads CSS from Bunny Fonts and then loads font files from the same host. ...

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

Replit embeds are usually simple right up until CSP gets involved. You drop in an iframe, everything looks fine locally, then production blocks it with a vague browser error. Or worse, your CSP is broad enough that it works, but now you’ve punched a bigger hole in your policy than you meant to. This guide is the version I wish I had handy the last few times I dealt with third-party embeds. ...

Tidal embeds look simple right up until your Content-Security-Policy blocks them. That’s the usual story with third-party media: the product team pastes an iframe, it works locally, then production CSP shuts it down and everyone blames security. The real fix is to decide what kind of CSP you want to run: strict and minimal, or practical and easier to maintain. For Tidal embeds, that tradeoff matters because you’re almost always dealing with an iframe, not a script widget you fully control. That changes which directives matter most. ...

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

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

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

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