Csp

CSP Examples Cookbook: Copy-Paste Security Headers Content Security Policy (CSP) is still one of the highest-impact browser defenses you can deploy in 2026. A good CSP reduces XSS risk, limits third-party script abuse, narrows data exfiltration paths, and makes supply-chain mistakes less catastrophic. The hard part is not the syntax. The hard part is shipping a policy that matches your stack. This cookbook gives you complete, copy-paste-ready CSP examples for common servers, frameworks, hosting platforms, and integrations. Each example is short, practical, and designed to be adapted with minimal changes. ...

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

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

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