A city services portal echoes webhook and form text into HTML pages. Reviewers flag reflected cross-site scripting risk. Which mitigation correctly addresses XSS?
Select an answer to reveal the explanation.
Short Explanation
Untrusted text in a page is like raw ingredients dumped straight into a finished plate—encode (or auto-escape) before it hits HTML or JavaScript. A firewall alone is not the XSS fix.
Full Explanation
Reflected XSS happens when untrusted webhook or form text is written into HTML or JavaScript without context-appropriate encoding. For the city services portal, the correct mitigation is to apply output encoding or framework auto-escape before rendering that text into pages. Encoding breaks the jump from data into executable markup so a crafted payload cannot run in a clerk’s browser.
Trusting the perimeter firewall to strip all script tags fails because XSS payloads have many encodings and contexts firewalls miss, and APIs may inject after the firewall. Requiring only that the user already has a session cookie before rendering the string fails—XSS often targets authenticated users precisely to abuse their session. Concatenating the untrusted string into a SQL WHERE clause so it never reaches HTML fails by trading XSS for SQL injection and does not address the HTML sink.
Exam caveat: attribute, JS, CSS, and URL contexts need different encoding; HTML-entity encoding alone is not enough inside a script block. Prefer framework auto-escape and avoid writing user strings into executable contexts.
Operational check: submit a benign <script>alert(1)</script> style probe in webhook text and confirm the page source shows encoded output, with CSP reports clean in staging.