Javascript

Zapier integrations look harmless until you remember what they really do: move untrusted data between systems at high speed. Names, emails, form answers, ticket content, CRM notes, webhook payloads, markdown blobs, HTML snippets — it all gets piped around and eventually lands in somebody’s UI. That’s where teams get burned. They think, “Zapier just passes data through,” and forget that passthrough data becomes dangerous the moment they render it in a browser, email preview, admin panel, or embedded app. ...

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

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

Luma event pages look simple on the surface: title, description, speaker bios, links, embeds, maybe a custom script or two. That simplicity is exactly why teams get sloppy with XSS. They assume “it’s just an event page,” then bolt on user-generated content, third-party widgets, and custom HTML until the page becomes a perfect little script execution engine. I’ve seen this pattern a lot. Event pages tend to be built fast, owned by marketing or community teams, and touched by engineers only when something breaks. That’s where XSS sneaks in. ...

SAPUI5 does a lot of the heavy lifting for output encoding, but I’ve seen teams get a false sense of safety from that. The framework helps, yes. It does not save you when you bypass its protections, render raw HTML, or trust backend data too much. If you build SAPUI5 apps, most XSS bugs come from a handful of repeat mistakes. They’re boring, predictable, and still very exploitable. Mistake #1: Assuming model data is always safe A common SAPUI5 habit is to bind model values directly into controls and assume the framework will handle everything. Often it does. But “often” is not a security strategy. ...

IFTTT applets look harmless right up until they start moving untrusted data between services. That’s the trap. A lot of teams treat automation glue as “not really part of the app,” then they pipe data from webhooks, email subjects, calendar titles, tweets, form submissions, or IoT device names straight into admin dashboards, notification centers, internal portals, and support tools. That’s where XSS shows up. The IFTTT side usually isn’t the vulnerable part. The bug tends to land in the system that consumes applet output. ...

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

A few years ago I helped clean up a form workflow that looked harmless on the surface: a static marketing site, a contact form powered by Getform, and a tiny “thank you” page that echoed back the user’s name. That last part was the problem. The team assumed Getform was “just handling submissions,” so they treated the returned data like trusted content. It wasn’t. A user-controlled field got pulled from the URL and dropped into the DOM with innerHTML. That turned a basic contact form into an XSS sink. ...