Welcome to XSS Prevention

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

A WAF can help with XSS prevention. It can also give your team a completely false sense of safety. I’ve seen this pattern too many times: a team buys a WAF, enables the default rules, blocks a few obvious <script> payloads, and then quietly assumes XSS is “handled.” That’s not how this works. A WAF is a useful layer, not a substitute for fixing how the app renders untrusted data. ...

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

XSS in innerHTML and dangerouslySetInnerHTML If you render attacker-controlled HTML, you are one bad string away from XSS. Two APIs show up constantly in real apps: the browser DOM API: element.innerHTML the React escape hatch: dangerouslySetInnerHTML Both do the same dangerous thing: they parse a string as HTML and inject it into the page. If that string contains active content, your app can execute attacker-supplied JavaScript. This is the reference I wish more teams had pinned in their repos. ...

Angular does a lot of XSS prevention for you. That creates a dangerous habit: people stop thinking about where HTML, URLs, and templates come from. Most Angular apps I review are not vulnerable because someone forgot to escape a string in interpolation. They break because someone worked around Angular’s safety model to make a feature ship faster. Usually that means dynamic templates, innerHTML, or bypassSecurityTrust... used like a global off switch. ...

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