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.

someone pasted a script tag and it ranuser input became codecross site scriptingscript injection in the browserXSS attackalert(1) popped up on my sitemy comment box runs JavaScriptcross-site-scripting vulnerability

See it

Live demo coming soon

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, HttpOnly and SameSite cookies so a stolen script cannot read the session, and a Content Security Policy without unsafe-inline as the net under everything you missed.

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 plus SameSite cookies, and a Content Security Policy with script-src 'self' plus nonces and no unsafe-inline. Cover stored, reflected, and DOM-based cases, and show me a proof-of-concept payload for each hole before you patch it.

You might have meant

input validation and contextual output encodingcontent security policycsrfsql injectionsecurity headers

Go deeper