A municipal app reflects user input into HTML responses without encoding. How should the tester classify the primary risk theme?
Select an answer to reveal the explanation.
Short Explanation
If the page echoes your input straight into HTML, a victim’s browser may treat attacker-controlled bits as code. That is the reflected XSS story — how bad it gets still depends on where it lands and what cookies or tokens are in play. It is not “just CSS.”
Full Explanation
Unencoded reflection of user input into HTML can enable reflected XSS, with impact depending on context and session handling. A municipal app that echoes input without encoding creates a client-side script injection theme that may steal sessions, deface citizen portals, or perform actions as the victim—severity tied to cookie flags, CSP, and where the reflection lands.
Unencoded reflection is not merely a CSS styling issue. HTML reflection does not always prove stored XSS in admin panels—that is a different persistence pattern. Reflection without encoding can affect browsers, not only PDF exports.
Exam caveat: classify XSS by reflection vs storage vs DOM and by sink context (HTML, attribute, JS). CPTS web answers should avoid over-claiming impact without session/cookie context.
Operational check: demonstrate a safe, RoE-compliant proof in the reflecting civic page, note HttpOnly/Secure/CSP mitigations, and recommend context-appropriate encoding and CSP hardening. Retest reflections after encoding/CSP changes on the municipal app and update severity if session-cookie flags already limit script theft. Context-aware encoding beats blanket HTML escaping myths when municipal templates mix attributes and scripts.