A transit portal builds page behavior from untrusted URL fragments that flow into DOM sinks. What XSS theme does that illustrate?
Select an answer to reveal the explanation.
Short Explanation
Sometimes the server never echoes the payload — the browser’s own JavaScript reads a fragment and drops it into a dangerous sink. That is DOM XSS: the bug lives in client-side handling. No classic reflected HTML required.
Full Explanation
DOM-based XSS arises when client-side scripts pass untrusted data into dangerous sinks, including cases where URL fragments drive page behavior without classic server-side reflection. A transit portal that builds behavior from untrusted fragments flowing into DOM sinks illustrates that theme: the browser executes attacker-controlled data through JavaScript even if the server never echoed the fragment into HTML.
This is not server-side include injection against FTP banners. Fragments do not imply SQL injection merely because they are in the URL. CSRF token optionality is a separate control issue, not the XSS class illustrated here.
Exam caveat: test client-side sources and sinks (location.hash, postMessage, etc.) as carefully as server reflections. CPTS web methodology includes DOM XSS for modern municipal SPAs.
Operational check: map fragment-driven JS paths in the transit portal, attempt controlled DOM sink proofs within RoE, and remediate with safe DOM APIs, sanitization, and CSP where applicable. Add DOM sink reviews to SPA release checklists for the transit portal so fragment-driven features get the same scrutiny as server templates. SPA route changes on transit portals frequently introduce new fragment sinks—retest after UI releases.