반사형 크로스사이트 스크립팅 (XSS)

Reflected Cross-Site Scripting is one of the oldest bugs on the web — and one of the most stubborn. Despite decades of warnings, modern apps keep shipping it. The reason is simple: the browser cannot tell which `<script>` tag was put there by your developers and which was injected by a malicious URL parameter. Both run with the same trust as the rest of your code, which means access to cookies, local storage, the DOM, and any session your visitor has open in that tab.

Reflected XSS appears when request input is returned in HTML in a context the browser can execute. Attackers can turn that behavior into links or form submissions that run script in another user's session.

An attacker who runs JavaScript in your origin can steal session cookies (unless they're HttpOnly), exfiltrate data the user can see, perform actions as the user (transfer funds, change passwords, post content), key-log inputs on the page, or pivot into a phishing overlay convincing enough that the user happily re-enters credentials.

Treat all user input as hostile and apply context-aware output encoding when rendering: HTML entities for body content, attribute escaping for HTML attributes, JavaScript string escaping for inline scripts, URL encoding for href/src. Modern frameworks (React, Vue, Svelte) escape by default — opt-out paths like dangerouslySetInnerHTML are the usual culprits, and they should run user input through DOMPurify first. Add a strict Content Security Policy with no `unsafe-inline` and a per-request nonce so injected scripts cannot execute even if the encoding fails. Set HttpOnly + Secure + SameSite=Lax on every session cookie so a successful XSS at least can't read your auth token. Defense in depth.

XSS prevention is not a single fix — it's a stack. Modern templating, strict CSP, HttpOnly cookies, and never trusting user input are each one layer. Skip any one of them and the next one carries the load.