Embeds

Calendly embeds look harmless. Paste a script, drop in a div, ship the feature. That’s exactly why they get teams into trouble. I’ve seen this pattern more than once: a marketing or growth team wants faster scheduling, engineering wires up Calendly, and over time the embed becomes dynamic. Someone adds query parameters for prefilled name, email, company, campaign tags, maybe even a “custom message” field pulled from the URL. Now the embed code is no longer static. It’s generating HTML or URLs from user-controlled input. ...

Notion embeds feel harmless. Paste a link, get a nice preview, move on. That’s exactly why teams get sloppy with them. I’ve seen engineers treat “embed” as a trusted content type, when it’s really just another path for untrusted input to land in your app. If your product accepts Notion pages, renders Notion-derived HTML, proxies embed URLs, or wraps third-party content in iframes, you’re dealing with XSS risk whether you planned for it or not. ...

Eventbrite embeds are convenient. You paste a script, drop in a container, and ticketing appears on your site without rebuilding checkout flows yourself. That convenience has a security cost. If you embed any third-party widget, you are effectively inviting someone else’s JavaScript into your page. From an XSS perspective, that changes your threat model fast. The real question is not whether Eventbrite is “safe” in some abstract sense. The question is what your page is exposed to when you integrate it, and which embed pattern gives you the least dangerous blast radius. ...

Cal.com embeds are convenient, but they also create one of my least favorite frontend security situations: third-party UI mixed with app code that was never designed for hostile input. The Cal.com script itself isn’t the usual problem. The problem is everything around it: how teams build embed URLs, how they pass prefill data, how they read query params, and how they inject user-controlled values into the page next to the widget. ...

Coda embeds look harmless right up until someone treats them like “just a bit of HTML from a trusted tool.” That’s the trap. I worked on a content-heavy app where editors could paste Coda doc links and get rich embedded content in articles. Nice feature. Fast to ship. Also a clean path to XSS once the implementation drifted from “embed a known provider” into “render whatever comes back.” The bug wasn’t exotic. No browser zero-day, no weird parser edge case. Just a familiar chain of bad decisions: ...

Typeform is mostly a hosted form product, which makes people assume XSS is “their problem.” That’s only half true. If you embed Typeform into your app, pass user-controlled values into hidden fields, render Typeform responses in your own admin panel, or glue it together with custom JavaScript, XSS becomes your problem fast. I’ve seen teams lock down their main app and then casually inject Typeform data into dashboards with innerHTML. That’s how you end up with a boring form turning into a stored XSS source. ...