Posts

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

Cross-site scripting in WordPress plugins usually comes down to one boring truth: untrusted data reached HTML, JavaScript, or an attribute without the right escaping. I’ve reviewed a lot of plugin code over the years, and the same patterns keep showing up: $_GET echoed into admin pages option values printed without escaping post meta dropped into attributes localized script data built unsafely AJAX handlers returning HTML stitched together from user input WordPress gives you the tools to avoid this. The hard part is using the right function for the right output context. ...

XSS defenses go wrong when teams treat “sanitize user input” like a single magic step. It isn’t. Different kinds of input need different handling, and some of the most common advice online is flat-out incomplete. My opinion: if you only remember one thing, remember this — validate for business rules, encode for output, and sanitize only when you intentionally allow HTML. That distinction matters because “sanitizing input” can mean wildly different things: ...

Power Apps gets sold as “low code,” which makes some teams assume “low risk.” That’s a mistake. I’ve seen Power Apps deployments where the frontend looked harmless, the data lived in Dataverse or SharePoint, and the team still shipped stored XSS because someone rendered user-controlled HTML inside an app component. The platform gives you a lot of guardrails, but the moment you start mixing user input, HTML text controls, custom pages, PCF components, embedded web resources, or data flowing in from Power Automate, you can absolutely create a mess. ...

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

Jekyll is a static site generator, which makes people assume it’s automatically safe from XSS. That’s a bad assumption. Static output can still ship dangerous HTML and JavaScript to every visitor. If untrusted content gets into your templates, markdown, front matter, data files, or generated JSON, you can absolutely create stored XSS in a Jekyll site. The fact that the site is “just files” doesn’t help once the browser starts parsing them. ...

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

Cognito Forms is convenient. That’s why teams use it. You get hosted forms, calculations, workflows, payments, and embeds without building the whole stack yourself. The security catch is the same one you get with any third-party form platform: user-controlled content eventually gets displayed somewhere. If that content is rendered unsafely in a browser, you have an XSS problem. For developers, the real question usually isn’t “Does Cognito Forms have XSS?” It’s “Where can XSS happen in the way we use Cognito Forms, and which defenses are actually worth the complexity?” ...