If you want to embed Eraser in a site with a sane Content Security Policy, you have a few choices. None of them are perfect. The right one depends on whether you care more about tight isolation, easy maintenance, or preserving a very strict policy posture. I’ve had to make this tradeoff on production apps, and the pattern is always the same: the embed itself is easy, the CSP around it is where the mess starts. ...
Embedding Apple Music looks simple right up until your CSP blocks it and leaves you staring at a blank iframe. I’ve hit this a few times on locked-down sites: the page loads fine, your own scripts work, and then the Apple Music player silently fails because frame-src or child-src doesn’t allow Apple’s embed origin. If you’re running a reasonably strict policy, you need to account for the iframe itself and, depending on your setup, any assets or network requests your page makes around it. ...
Twitch embeds look simple right up until CSP gets involved. Then you get a blank box, a console full of errors, and a lot of bad advice telling you to just add *.twitch.tv everywhere and move on. That usually “works,” but it’s sloppy and often still incomplete. If you’re embedding a Twitch stream or chat on a site with a real Content Security Policy, there are a handful of mistakes I see over and over. Most of them come from misunderstanding which side controls what: your page’s CSP controls what your page is allowed to load, while Twitch’s own embed rules control whether Twitch will agree to render inside your page at all. ...
Loom embeds look simple: paste an iframe, ship it, move on. Then CSP blocks it, the video area goes blank, and somebody “fixes” it by slapping https: into frame-src or loosening half the policy. I’ve seen this happen more than once. Loom is exactly the kind of third-party embed that exposes weak CSP habits: developers guess at directives, over-allow sources, or forget that an iframe usually pulls in more than one origin. ...
Ghost embeds are easy to drop into a page and easy to forget from a CSP perspective. That’s where people get burned: the embed works in development, then production CSP blocks it, or worse, someone loosens the policy with script-src * and calls it done. Don’t do that. If you’re embedding Ghost content, membership widgets, or Portal-related UI on your site, you need to explicitly allow the right sources and keep the policy tight everywhere else. The good news is Ghost’s embed surface is pretty manageable if you approach it methodically. ...
TikTok embeds look simple: paste a blockquote, load their script, done. Then your CSP blocks it and suddenly you’re staring at a blank box, console noise, and a product manager asking why the campaign page is broken. I’ve seen this pattern a lot. Teams start from a pretty strict policy, add TikTok, and either overcorrect by allowing half the internet or undercorrect and leave the embed half-broken. The sweet spot is narrower than people think. ...
Reddit embeds look simple until your CSP starts blocking them. I’ve hit this a few times: product wants a Reddit post embedded on a marketing page, security wants a tight policy, and suddenly you’re trying to figure out whether you need frame-src, script-src, connect-src, or all three. The answer depends on how you embed Reddit, and that choice has real security and maintenance tradeoffs. If you’re building for a developer audience, the biggest mistake is treating “support Reddit embeds” as one CSP change. It’s not. There are a few patterns, and each one expands your policy in different ways. ...
Instagram embeds are one of those things that look simple until CSP gets involved. You paste the embed code, reload the page, and suddenly the post is blank, the console is yelling about blocked frames or scripts, and someone suggests adding https: to half your policy. That usually “works,” but it also wrecks the point of having CSP in the first place. If you want Instagram embeds and a CSP that still means something, you need to decide which tradeoff you’re willing to accept. ...
Spotify embeds are simple until your CSP blocks them. You paste the iframe, reload the page, and get a blank box or a browser console full of Refused to frame errors. I’ve hit this enough times that I keep a tiny checklist for it. This guide is that checklist, with policies you can copy-paste. If you only need the shortest possible answer: Spotify embeds need frame-src https://open.spotify.com If your page itself is allowed to be embedded nowhere, keep frame-ancestors 'none' You usually do not need to loosen script-src for a plain Spotify iframe embed If your CSP is based on default-src 'self', you must explicitly allow Spotify in frame-src The basic Spotify embed HTML A typical Spotify embed looks like this: ...
If you embed Typeform, SurveyMonkey, Google Forms, or similar widgets, CSP gets annoying fast. The failure mode is usually the same: the survey box is blank, the console screams about frame-src or script-src, and someone “fixes” it by throwing https: into half the policy. That works, but it also guts the point of CSP. I’d rather ship a tight policy and open only what the embed actually needs. The common CSP directives for survey embeds For most survey providers, these are the directives that matter: ...