A library comment field stores script that later runs in an administrator’s browser. Which XSS class best describes that pattern?
Select an answer to reveal the explanation.
Short Explanation
The nasty part of stored XSS is the delay: plant it once, and it can fire later when an admin opens the thread. That persistence is why it often outranks a one-off reflected bounce. Comments that keep script for privileged eyes are a classic stored class.
Full Explanation
Stored XSS persists malicious content and later executes in another user’s browser—here, a library comment that runs in an administrator’s browser. That class often carries higher impact potential because privileged staff become victims without repeating the injection themselves, threatening admin sessions that manage patron systems.
Comments that persist are not “reflected XSS only.” Administrator browsers frequently load server-rendered HTML, so “DOM XSS only” is an incomplete label for this pattern. It is not a non-browser “CSR-only” issue that cannot execute.
Exam caveat: stored XSS impact rises with who views the content—admin/moderator sinks deserve elevated severity in civic apps. Distinguish stored from reflected/DOM in report taxonomy.
Operational check: confirm persistence and admin rendering paths, use a non-destructive proof payload within RoE, rotate any exposed admin sessions, and remediate output encoding plus input validation on the comment feature. Prioritize stored XSS in admin-visible library workflows above low-traffic public fields when ranking remediation for privileged impact. Admin-only comment moderation views are high-value stored-XSS sinks in library workflows.