Web-Security

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

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

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

IBM Maximo is one of those platforms where XSS problems rarely come from the shiny marketing demo path. They usually come from years of customizations: automation scripts, JSP tweaks, web client extensions, integration messages rendered in the UI, and “quick” fixes that stayed in production for a decade. If you work on Maximo, you need to think about XSS differently than you would in a small React app. Maximo mixes server-rendered UI, legacy components, rich client behavior, and lots of user-controlled business data. That combination is perfect for reflected, stored, and DOM-based XSS if output handling is sloppy. ...