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: ...
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. ...
React Native developers often treat WebView like a harmless rendering box. It’s not. It’s a browser surface with script execution, DOM access, navigation, message passing, and all the old web security problems packed into a mobile app. That matters because teams frequently use WebView for things like: rendering CMS content showing support articles embedding payment or auth flows previewing user-generated HTML injecting app state into a page running custom JavaScript with injectedJavaScript If untrusted data reaches that surface, you can absolutely end up with XSS-like behavior inside your app. The impact is different from a classic browser XSS, but the bug is still real: attacker-controlled JavaScript runs in your app’s web context. ...
Telegram bots feel deceptively safe. A lot of developers assume the chat interface somehow neutralizes frontend risk. It doesn’t. The bot itself may only send messages, but the moment you render Telegram-controlled content inside a browser, an admin dashboard, a support console, or a Telegram Web App, you’re back in classic XSS territory. I’ve seen this pattern more than once: the bot is harmless, the backend is simple, and then someone builds a quick “internal” moderation UI that injects chat messages into innerHTML. That internal tool becomes the easiest path to account takeover. ...
Svelte’s {@html} is one of those features that feels harmless right up until it isn’t. It solves a real problem: sometimes you need to render trusted HTML. CMS content, rich text, server-generated markup, documentation snippets, email previews — all valid use cases. But {@html} is also the fastest way to turn a Svelte app into an XSS delivery mechanism if you feed it untrusted input. This guide is the practical version: what’s dangerous, what actually works, and what I’d ship. ...
Obsidian plugin development feels deceptively safe. You are not building a public website. You are writing code for a note-taking app, usually for power users, often for yourself first. That mindset is exactly why XSS bugs slip in. The UI still renders HTML. The app still runs JavaScript. The plugin still touches untrusted content from notes, frontmatter, sync sources, APIs, and other plugins. And because Obsidian sits on Electron, a bad XSS bug can feel worse than the browser kind. Sometimes it is “just” UI injection. Sometimes it is account token theft from a plugin settings panel. Sometimes it becomes local file access or remote code execution territory if the plugin mixes unsafe rendering with privileged APIs. ...
Drift is easy to drop into a page, which is exactly why people get sloppy with it. I’ve seen teams treat chat widgets like harmless marketing glue: paste the vendor snippet, pass a few user fields, and move on. That mindset creates XSS problems fast. The widget itself may be hosted by Drift, but the dangerous part is usually the code around it: how you inject the snippet, how you pass user-controlled data, and how your app renders data collected through chat flows. ...
Chat feels harmless until someone sends "<img src=x onerror=alert(1)>" and your UI happily executes it. I’ve seen this exact pattern in real-time apps: the backend is fine, Ably is delivering messages exactly as designed, and the browser becomes the weak point because the frontend treats chat content like trusted HTML. That’s the whole bug. This case study walks through a typical Ably chat setup, the vulnerable version I keep seeing in production, and the cleaned-up version that blocks XSS without making the chat experience miserable. ...