Javascript

Webflow gets marketed like a safe visual builder, and to be fair, it does remove a lot of classic XSS footguns. If your team is comparing platforms or deciding how much trust to place in “no-code” output, that matters. But “harder to mess up” is not the same thing as “immune to XSS.” That’s the right frame for Webflow: lower default XSS exposure than hand-rolled sites or plugin-heavy CMS setups, but still very capable of shipping unsafe script behavior when developers add custom code, embeds, or untrusted content pipelines. ...

Outlook web add-ins are a weird security boundary. They look like normal web apps because they are built with HTML, CSS, and JavaScript. But they run inside Outlook, interact with mailbox data, and often get trusted more than they should. That mix is exactly why XSS in Outlook web add-ins deserves special attention. If you already know how to prevent XSS in a regular web app, you are not done. Outlook add-ins add their own constraints, APIs, hosting model, and trust assumptions. Some of those help. Some make things worse. ...

Android WebView is one of those features that feels harmless right up until it becomes your app’s biggest security problem. If you render untrusted HTML, expose Java objects to JavaScript, or load mixed app and remote content into the same WebView, you are building an XSS target. The twist is that XSS in WebView is often worse than browser XSS, because the payload can sometimes reach native app capabilities. That changes the impact from “someone ran JavaScript in a page” to “someone ran JavaScript inside my app.” ...

Third-party chat widgets are convenient, but they also widen your XSS attack surface. Tidio is no exception. The widget itself is usually loaded from Tidio’s infrastructure, but the real risk tends to come from how developers pass data into it: visitor names, emails, custom variables, query parameters, CRM fields, and anything else that can end up rendered in the widget UI, agent panel, or related pages. If you treat Tidio integration as “just paste the script and move on,” you’re asking for trouble. ...

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

Figma plugins feel deceptively safe. A lot of developers assume, “It’s a design tool, not a public website, so XSS probably isn’t a big deal here.” That assumption gets people into trouble fast. Figma plugins are basically little web apps glued onto a privileged plugin runtime. You still have HTML, JavaScript, message passing, user-controlled content, and the usual temptation to throw untrusted strings into innerHTML. That’s enough for XSS. The exact blast radius is different from a normal browser app, but the root problem is the same: untrusted data reaches a dangerous sink and runs as code. ...

If you embed the Chatwoot widget, you’re adding a live JavaScript application to your site. That’s fine. I like Chatwoot. But I’ve seen teams treat the widget snippet like a harmless copy-paste include, then forget it touches the DOM, handles user-controlled content, and often runs with broad trust in production. That’s where XSS mistakes show up. The Chatwoot widget itself isn’t the only thing to think about. The bigger problem is usually how developers pass data into it, how they customize the launcher, and how they weaken their own defenses to “make the widget work.” ...

Tally is a nice form tool. It’s fast to embed, easy to customize, and teams ship it without much ceremony. That convenience is also where people get sloppy. The Tally form itself is usually not the weak point. The mess tends to happen in the code around it: unsafe embed options, rendering form answers back into your app, trusting webhook payloads, or mixing user-controlled values into the DOM. That’s where XSS shows up. ...

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

Lit does a lot of the right things by default. That’s the good news. The bad news is that teams get comfortable, then punch straight through Lit’s safety model with unsafeHTML, sloppy URL binding, or “just this one” direct DOM write. I’ve seen this happen in otherwise solid codebases. If you build web components with Lit, here’s the reference guide I’d want next to me during code review. The short version Lit escapes text interpolations in templates: ...