Web-Security

WebSockets make it ridiculously easy to stream untrusted data straight into the DOM. That’s why XSS bugs in real-time apps are so common: chat, notifications, dashboards, admin consoles, trading UIs, collaborative editors — they all take server messages and render them fast, often without the same discipline teams apply to normal HTTP responses. I’ve seen teams lock down templates, escape server-side HTML, add CSP, and still ship XSS because one socket.onmessage handler quietly did innerHTML = data.message. ...

Angular gives you better XSS defaults than most frontend frameworks. That’s the good news. The bad news: teams still break those protections all the time. I’ve seen this happen in real apps that started out safe, then picked up “just one quick workaround” for rich text, embeds, markdown, or dynamic links. A few months later, the app is full of bypassSecurityTrustHtml, direct innerHTML writes, and helper pipes that quietly turn untrusted input into executable code. ...

WeChat mini-programs look like web apps, smell like web apps, and absolutely still give teams a false sense of security around XSS. I’ve seen this mistake a lot: a team assumes “it’s not running in a normal browser, so classic XSS doesn’t really apply.” That’s the wrong mental model. The attack surface is different, the rendering model is more constrained, and some browser features are missing, but untrusted data is still untrusted data. If your mini-program renders attacker-controlled content, builds templates carelessly, or bridges unsafe data into native-like APIs, you can still end up with script injection, UI redress issues, data theft, or malicious action execution. ...

WKWebView is one of those APIs that looks harmless until you ship a hybrid app, load a little untrusted HTML, and accidentally hand JavaScript access to native code. That’s where XSS in iOS apps gets ugly. Browser XSS is already bad. XSS inside WKWebView can be worse because the payload may not stop at stealing cookies or rewriting the DOM. If your app exposes native functionality through WKScriptMessageHandler, custom URL schemes, or sloppy navigation delegates, injected JavaScript can start poking at app internals. ...

Browser extensions are one of the weirdest XSS threat sources because the vulnerable code often isn’t yours. Your app can have solid output encoding, a decent CSP, and disciplined frontend code, then a user installs an extension that injects scripts, mutates the DOM, rewrites requests, or shoves untrusted HTML into your page. Suddenly your clean security model gets dragged into someone else’s mess. For developers, the hard part is that extension-driven XSS sits in an uncomfortable middle ground: ...

Cross-site scripting is still one of the easiest ways to turn a tiny frontend mistake into a full account takeover. I’ve seen teams spend weeks hardening auth flows while leaving a innerHTML assignment sitting in a comment widget like a loaded gun. The tricky part is that “XSS payloads” are not all the same. Some rely on raw <script> injection. Some abuse HTML attributes. Some hide inside JavaScript URLs, SVG, Markdown, or template rendering. If you only block one shape, the others get through. ...

Budibase makes it easy to ship internal tools fast. That speed is great for product teams and terrible for security if nobody stops to ask a basic question: where does this data come from, and how is it rendered? That question matters because XSS in Budibase apps usually does not come from some dramatic “hacker-only” feature. It comes from normal app-building behavior: user-generated content, dynamic bindings, custom components, markdown-ish fields, embedded HTML, and API data that gets trusted too early. ...

SurveyMonkey feels harmless because it’s “just forms.” That mindset gets teams into trouble. I’ve seen developers lock down their main app, then casually embed survey content, pipe responses into dashboards, send answers into admin panels, and render “custom thank you” pages with basically no output encoding. That’s how XSS sneaks in: not through the survey vendor itself, but through the glue code around it. If you use SurveyMonkey in a website, a customer portal, or an internal reporting tool, the risky parts are usually: ...

SharePoint gives you a lot of ways to render user-controlled content, and that’s exactly why XSS keeps showing up in SharePoint customizations. The platform itself has decent guardrails, but the moment you add SPFx components, classic scripts, custom forms, REST-driven UI, or “just a little HTML” from a list field, you can create a mess. This guide is the practical version: where XSS shows up in SharePoint, what safe code looks like, and what I’d actually recommend in a real tenant. ...

I’ve cleaned up XSS issues in enough Rails apps to know the pattern: the team assumes Rails auto-escaping has them covered, then one helper, one html_safe, or one “temporary” rich text feature quietly blows a hole in the whole thing. Rails does a lot right by default. That’s true. But most real XSS bugs in Rails don’t come from ERB tags alone. They come from the seams: helpers, JavaScript interpolation, admin tooling, markdown rendering, ActionText assumptions, and legacy code that predates current defaults. ...