HubSpot chat is one of those integrations that looks trivial right up until CSP starts blocking half of it. I’ve seen this pattern a lot: the base site already has a decent policy, someone drops in the HubSpot tracking/chat script, the widget silently fails, and the first reaction is to throw 'unsafe-inline' or https: into the policy until the errors go away. That works, but it also wrecks the whole point of having CSP. ...
FullStory is one of those tools that security teams side-eye and product teams love. Session replay, event capture, rage clicks, funnels — great for debugging real user behavior, but it also means you’re injecting a third-party script that phones home constantly. That makes Content Security Policy a real concern, not a checkbox. If you add FullStory without thinking through CSP, you usually get one of two outcomes: FullStory silently breaks and nobody notices until analytics goes dark. Someone opens the policy way too far with https: and 'unsafe-inline', and now your CSP is mostly decorative. I’d rather avoid both. ...
If you build web apps, CSP is one of those controls that feels clean and satisfying. You define what the browser may load, block everything else, and sleep a little better. Then email shows up and ruins the neat mental model. CSP for email templates and HTML emails sounds like a natural extension of web security. Same HTML, same browser engine somewhere in the stack, same risks from injected content. But email clients are a different universe. Some strip tags. Some rewrite links. Some proxy images. Some ignore modern security controls entirely. And many of them treat your carefully crafted HTML like a suspicious package. ...
Feature flags sound harmless until they turn into “run arbitrary code from a remote dashboard.” I’ve seen teams build a custom flag system, then quietly smuggle in dynamic script loading, inline config blobs, third-party SDKs, and admin-controlled HTML. That’s exactly where Content Security Policy starts pulling its weight. If you’re building a custom flag system, CSP won’t design it for you. What it does is force you to be honest about how the system actually works. Are flags just booleans? Are they JSON payloads? Do they decide which already-shipped component renders? Or are they effectively a remote code execution mechanism with nicer branding? ...
I’ve seen a lot of Rails apps with one of two CSP setups: no policy at all a policy that exists mostly to silence browser errors Neither gives you much protection. Rails actually makes CSP pretty workable, especially once you stop treating it like a static header and start treating it like application code. Here’s a real-world style case study based on the kind of policy you’ll see on production marketing and SaaS sites, including analytics, consent tooling, WebSockets, and a few legacy frontend habits that make CSP harder than it should be. ...
Browser extensions make CSP debugging weird. You lock down script-src, remove inline code, add nonces, maybe even deploy strict-dynamic, and then someone on the team says: “Why is this extension still injecting stuff into our page?” Or worse: “Why is our app breaking only for users with ad blockers?” That confusion usually comes from one bad assumption: people expect a site’s CSP to control browser extensions the same way it controls page code. It doesn’t. ...
Educational platforms are a CSP minefield. A normal marketing site might load a few scripts, an analytics tag, and maybe a video embed. An LMS loads SSO flows, SCORM packages, grading tools, PDFs, discussion widgets, proctoring apps, webinar platforms, analytics, and random third-party course content written by people who have never heard of CSP. So the trick is not “make CSP strict at all costs.” The trick is building a policy that blocks obvious abuse without breaking the actual learning experience. ...
Content Security Policy and Subresource Integrity solve different problems, and they work best when you treat them as a pair. CSP answers: what sources am I willing to trust? SRI answers: is this exact file the one I meant to load? That distinction matters. I still see teams deploy one and assume they’re covered. They’re not. If you load a third-party script from an allowed domain in CSP, CSP is happy. But if that third-party file changes unexpectedly, CSP won’t help. SRI will. ...
Content Security Policy has a reputation problem. A lot of teams either treat CSP like a magic anti-XSS shield, or they avoid it because they assume it will break everything. Both takes are wrong. CSP is powerful, but it’s also easy to misuse in ways that give you a nice-looking header and very little real protection. I’ve seen plenty of production policies that look serious because they’re long, but collapse the moment an inline script sneaks in or a third-party script gets too much trust. ...
Next.js developers usually think about CSP at the page level: block inline scripts, add nonces, lock down third-party tags. That’s the right instinct, but API routes deserve attention too. Strictly speaking, CSP is mostly a browser-enforced policy for documents and some subresources. Your JSON API endpoint isn’t executing scripts in the browser, so a Content-Security-Policy header on /api/users won’t do much for a normal application/json response. That’s the part people skip. ...