Sanitization

XSS in innerHTML and dangerouslySetInnerHTML If you render attacker-controlled HTML, you are one bad string away from XSS. Two APIs show up constantly in real apps: the browser DOM API: element.innerHTML the React escape hatch: dangerouslySetInnerHTML Both do the same dangerous thing: they parse a string as HTML and inject it into the page. If that string contains active content, your app can execute attacker-supplied JavaScript. This is the reference I wish more teams had pinned in their repos. ...

Angular does a lot of XSS prevention for you. That creates a dangerous habit: people stop thinking about where HTML, URLs, and templates come from. Most Angular apps I review are not vulnerable because someone forgot to escape a string in interpolation. They break because someone worked around Angular’s safety model to make a feature ship faster. Usually that means dynamic templates, innerHTML, or bypassSecurityTrust... used like a global off switch. ...

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

VS Code extension authors often assume XSS is “just a web app problem.” That’s a mistake. If your extension uses a webview, custom editor, notebook renderer, or any HTML UI at all, you’re building a mini browser surface inside an editor that developers trust deeply. That trust changes the impact. A sloppy XSS bug in a marketing site is bad. A sloppy XSS bug in a VS Code extension can expose workspace data, abuse extension APIs indirectly, phish secrets, or trick users into running commands. ...

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

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

Make is great at moving data between systems. That convenience is exactly why XSS can sneak in so easily. I’ve seen teams assume XSS is only a frontend bug. Then they wire Make into forms, CRMs, CMS tools, Slack, email builders, internal dashboards, and webhook handlers. Suddenly untrusted input is flowing through ten services, getting reformatted three times, and landing in HTML somewhere nobody reviewed carefully. That’s the real problem with XSS in Make automations: Make usually isn’t the final vulnerable layer, but it can absolutely become the delivery mechanism. ...

Cross-site scripting gets most of the attention, but SVG-based attacks keep showing up in bug bounty reports, file upload flaws, and chat apps that “support rich images.” If you build web apps, you should treat SVG as part image, part document, part script container, and part footgun. The tricky part is that XSS and SVG attacks are not competing categories. SVG attacks often become XSS. That overlap is exactly why teams underestimate them. ...

Alpine.js feels safe because it stays close to plain HTML. That’s part of why people trust it too much. I’ve seen teams assume “small framework” means “small attack surface.” Not true. Alpine gives you powerful ways to bind data into the DOM, evaluate expressions, and react to user input. Those same features can become XSS sinks if you feed them untrusted data. If you build with Alpine, the good news is simple: most XSS issues come from a handful of dangerous patterns. Avoid those, and Alpine is pretty manageable. ...

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