Javascript

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

Single-page apps make XSS easier to hide. You load one shell, fetch data later, stitch UI together in the browser, and somewhere along the way somebody says, “It’s fine, the framework escapes it.” Sometimes that’s true. Sometimes it’s very, very false. I’ve seen teams assume that moving from server-rendered templates to React or Vue magically solves XSS. It doesn’t. SPAs change where the bug happens, not whether it can happen. ...

Discord bots themselves do not execute browser JavaScript inside Discord messages, and that lulls a lot of developers into the wrong threat model. I’ve seen this play out the same way over and over: someone builds a bot, then adds a web dashboard, moderation panel, transcript viewer, ticket system, or message log page. The bot becomes the source of untrusted content, and the browser-facing parts become the XSS sink. That distinction matters. The bug usually is not “Discord has XSS.” The bug is “my bot collected hostile input from Discord and I rendered it into HTML like an idiot.” ...

Freshchat is convenient. Drop in a script, get customer messaging, move on. That convenience is exactly why widget security gets hand-waved until someone notices user-controlled HTML, sketchy postMessage handling, or a CSP exception list that has turned into a small novel. If you’re assessing XSS risk in the Freshchat widget, the real question usually isn’t “is Freshchat vulnerable?” It’s “what XSS exposure do I create by embedding and customizing it on my site?” ...

Tito is great for event registration, but I’ve seen teams treat embedded registration flows like a trusted UI just because it comes from a reputable platform. That’s where XSS bugs creep in. The weak spots usually aren’t Tito itself. They’re the custom wrappers, post-registration pages, attendee dashboards, and little bits of JavaScript glued around the form. If you’re collecting attendee names, company names, dietary notes, discount codes, or custom answers and then displaying them anywhere in your app, you have an XSS surface. Tito registration data is user input. Treat it like any other untrusted data. ...

Stimulus feels safe at first glance. It does not ship a template engine, it nudges you toward small controllers, and most of the code you write is “just DOM code.” That last part is exactly where XSS creeps in. Stimulus does not create XSS by itself. Your controller code does. If you take untrusted data from data-* attributes, query params, server-rendered HTML fragments, or API responses and push it into dangerous DOM sinks, you have DOM XSS. Stimulus makes those flows easy to write, which means you need a clear rule set. ...

Slack apps feel safer than regular web apps at first glance. A lot of UI is rendered by Slack, not by your own frontend, so the usual DOM-based XSS panic seems less relevant. That feeling is only half true. Slack apps still get XSS in a few predictable places: web dashboards for app config OAuth install flows message content reflected into your own admin UI link unfurl previews rendered by your backend Home tabs or modals when developers mix trusted Slack fields with untrusted external data any custom web view opened from a Slack app The tricky part is that Slack removes some classes of frontend mistakes while leaving others completely intact. So the right question is not “can Slack apps get XSS?” It’s “which Slack surfaces reduce XSS risk, and which ones just move it somewhere else?” ...

FormBucket is convenient because it lets you collect form submissions without building a full backend. That convenience also creates a trap: teams treat it like a harmless inbox, then start rendering submission data in dashboards, emails, admin tools, thank-you pages, or internal review apps. That’s where XSS shows up. The problem usually isn’t FormBucket itself. The problem is what developers do with untrusted form data after it lands. If you accept name, message, company, or notes from a public form, assume every field is attacker-controlled HTML and JavaScript. If you forget that even once, you get stored XSS, reflected XSS, or DOM-based XSS depending on how you display it. ...

XSS in URL parameters URL parameters are one of the most common places where XSS starts. They feel harmless because they arrive as plain text: https://example.com/search?q=shoes Then somebody reads q, drops it into the page, and now you have script execution. The vulnerable pattern is usually boring: const params = new URLSearchParams(window.location.search); const q = params.get('q'); document.getElementById('search-label').innerHTML = `Results for: ${q}`; If q is: <img src=x onerror=alert(1)> you just handed the browser executable HTML. ...

Excel web add-ins are just web apps wearing an Office badge. That sounds obvious, but teams forget it all the time. I’ve seen this play out the same way more than once: a team builds a task pane add-in, treats workbook data like “internal content,” renders it into the DOM, and accidentally creates a clean XSS path inside Excel. The UI looks harmless. The payload comes from a spreadsheet cell, a custom function result, or a document setting. Then somebody pastes attacker-controlled content into a workbook, shares it, and the add-in executes script in the task pane. ...