Stored Cross-Site Scripting (XSS)

What Is Broken and Why

Stored XSS persists because user-supplied content is saved to a database or file system and later retrieved and rendered without output encoding. Unlike reflected XSS, no social engineering link is needed — every user who views the affected page triggers the payload. High-privilege pages (admin panels, audit logs, user management) that display stored user input are particularly dangerous as they can lead to full application compromise.

Key Signals

• User-controlled fields stored and redisplayed: names, bios, comments, addresses, file names
• Email fields, address fields, or free-text inputs that appear elsewhere in the UI
• Admin panels or logs that display raw user-submitted data
• File upload features that reflect filename or metadata in the browser
• Shopping cart items, support ticket content, or CMS posts rendered to other users
• Source variables: PHP $_GET, $_POST, $_REQUEST, $_FILES; ASP Request.QueryString, Request.Form; JSP request.getParameter, doGet, doPost