Web-Security

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

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

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

Paperform makes it easy to ship forms fast. That convenience is also where teams get sloppy. I’ve seen the same pattern over and over: a safe hosted form gets wrapped in unsafe frontend code, piped through insecure automations, or embedded into pages that trust user input way too much. Paperform itself isn’t the whole story. XSS usually shows up in the code around it: confirmation pages, embed wrappers, analytics hooks, custom HTML blocks, webhook consumers, and admin dashboards displaying submissions. ...