XSS (cross-site scripting)
Attacker text gets rendered as real code in someone else's browser, so their script runs with your victim's session.
See it
What it is
Three flavors. Stored XSS sits in your database (a comment, a bio, a filename) and fires for every visitor who loads the page. Reflected XSS bounces off a query parameter you echo back, delivered by a link someone clicks. DOM-based XSS never touches your server at all: client JS reads location.hash or a URL param and writes it into innerHTML. Real payloads are rarely alert(1); they steal session cookies, keylog the login form, or fire authenticated requests as the victim.
Every place user-controlled text meets HTML is a candidate. React, Vue, and Svelte escape by default, which kills the boring cases, and then people reopen the door with dangerouslySetInnerHTML, v-html, or the Svelte html block. Same goes for an href bound to a user value (javascript: URLs still work), an img src, and anything assembling markup with template strings.
Blocklisting the word 'script' is theatre: the payload can be an onerror on a deliberately broken img, an svg onload, or a data URI. What actually holds: contextual escaping by default, DOMPurify when you must accept rich text, and a Content Security Policy without unsafe-inline as the net under everything you missed.
Be honest about what cookie flags buy you. HttpOnly stops injected script from reading the cookie directly, which raises the cost of stealing a session for reuse elsewhere. SameSite is a CSRF mitigation and does nothing here, because the injected code is already running on your origin: it can call your API with the victim's cookies attached, read the response, and act as them without ever seeing the cookie value. Neither flag fixes XSS. They shrink one consequence of it.
Ask AI for it
Audit this codebase for XSS and fix what you find. Locate every sink where user-controlled data reaches HTML: dangerouslySetInnerHTML, innerHTML, outerHTML, document.write, v-html, Svelte html blocks, href and src bound to user values, and any handler built from a string. For each one, either switch to escaped text rendering or run it through DOMPurify with an explicit tag and attribute allowlist. Then add the layers behind it: HttpOnly cookies to limit outright session theft, SameSite for the separate CSRF problem, and a Content Security Policy with script-src 'self' plus nonces and no unsafe-inline. Do not treat either cookie flag as an XSS fix; injected code on our own origin can still make authenticated same-origin requests. Cover stored, reflected, and DOM-based cases, and show me a proof-of-concept payload for each hole before you patch it.