If you embed Fillout on a site with a real Content Security Policy, you’ll usually hit one of two problems fast: the form iframe gets blocked the form loads, but some supporting requests fail silently This is normal. CSP is doing its job. The trick is knowing which directives matter for Fillout and which ones don’t. A lot of developers throw https: into half the policy and call it done. That works, but it defeats the point of having CSP in the first place. ...
Service Workers and CSP have an awkward relationship. A lot of developers assume CSP either fully controls what a Service Worker can do, or barely touches it at all. Neither is true. The browser applies CSP in a few very specific places, and if you get those wrong, your worker won’t register, won’t update, or will quietly fail in ways that are annoying to debug. I’ve seen teams lock down page CSP nicely, then wonder why their offline cache logic broke after moving sw.js behind a CDN path, or why a worker-installed fetch started behaving differently than page fetches. The root problem is usually the same: they’re treating the page, the worker script, and worker-initiated requests as one security context. They aren’t. ...
Svelte 5 doesn’t make CSP hard, but it does force you to be honest about how your app renders, hydrates, and injects code. That’s a good thing. If you’re building with Svelte 5 and runes, the CSP story is mostly about three things: avoiding inline script and style surprises handling nonces correctly for SSR not breaking hydration or third-party tooling Runes themselves don’t need special CSP directives. $state, $derived, and $effect are compile-time language features. CSP doesn’t care that you used runes. CSP cares whether the generated output includes inline JavaScript, inline styles, eval-like behavior, or external resources from origins you didn’t allow. ...
ConvertKit forms are simple to embed, but they’re annoying from a CSP perspective for one reason: most teams start with a tight policy, paste in the form snippet, and then the browser blocks half of it. I’ve had to fix this a few times. The pattern is usually the same: the form loader script is blocked inline styles or scripts get blocked form submission fails because connect-src or form-action is too strict success messages or embeds break inside an iframe This guide is the practical version: what to allow, what to avoid, and copy-paste policies you can start with. ...
Paperform is easy to embed and easy to break with a bad CSP. If you run a locked-down site and drop in a Paperform embed, you’ll usually hit one of these: the iframe refuses to load form assets get blocked custom scripts around the embed stop working submissions fail because connect-src is too strict your own site can’t frame Paperform because frame-src is missing This guide is the practical version: what to allow, when to allow it, and copy-paste policies you can start with. ...
AWeber form embeds are the kind of thing teams paste into production on a Friday afternoon and only think about again when signups mysteriously stop working. I’ve seen this pattern a lot: the site starts with a pretty solid Content Security Policy, marketing drops in an email signup form, and suddenly the browser console fills with CSP violations. The usual reaction is to loosen the policy until the errors disappear. That works, but it also trashes the point of having CSP in the first place. ...
If you embed Commento, your CSP gets more interesting fast. Comment systems are one of those features that look harmless in product planning and then quietly punch holes in an otherwise tight policy. You add one script, maybe an iframe, maybe an API endpoint, and suddenly your neat default-src 'self' turns into a pile of exceptions nobody wants to touch six months later. Commento is still one of the cleaner options compared to heavier third-party widgets. That’s the good news. The less-good news: the “right” CSP for Commento depends heavily on how you deploy it. ...
If you use Clerk for auth, Content Security Policy gets awkward fast. Clerk is easy to drop into a React or Next.js app. CSP is not. The friction shows up the moment you try to lock down script-src, remove unsafe-inline, or support Clerk’s hosted flows, widgets, and frontend API calls without punching giant holes in your policy. I’ve dealt with this in production, and the pattern is always the same: auth works fine until someone turns on a real CSP, then sign-in modals break, frontend API calls fail, or a wildcard gets added “temporarily” and never leaves. ...
Jotform is one of those services that looks simple from the outside: paste an embed, publish the page, done. Then CSP blocks it. Usually the first breakage shows up as: the form iframe never loads custom scripts from Jotform get refused form submissions fail silently file uploads or payment widgets break the browser console fills with Refused to frame, Refused to connect, or Refused to load script If you’re embedding Jotform on a site with a real Content Security Policy, you need to explicitly allow the Jotform origins your embed uses. There isn’t a single universal one-liner that covers every Jotform feature, because the exact domains can vary by embed type, region, and enabled integrations. ...
I’ve seen this exact problem a bunch of times: a team has a pretty decent Content Security Policy, marketing wants Intercom, someone pastes the vendor snippet into the site, and suddenly the browser console looks like a crime scene. The hard part isn’t getting Intercom to load. The hard part is getting it to load without wrecking a policy that was actually doing useful work. Here’s a realistic case study using a real baseline CSP from headertest.com, then tightening it up for Intercom live chat with minimal blast radius. ...