A cookie-authenticated civic admin form accepts POST from the browser. Attackers could trick a logged-in clerk’s browser into submitting a cross-origin POST. Which mitigation specifically addresses CSRF?
Select an answer to reveal the explanation.
Short Explanation
Being logged in is not the same as meaning to press that button—CSRF needs a token (or a strict SameSite policy) on state-changing posts, not just “session exists.”
Full Explanation
CSRF tricks a logged-in browser into issuing a state-changing request the user did not intend. For a cookie-authenticated civic admin form, the specific mitigation is to require a per-session anti-CSRF token (or equivalent SameSite=Strict/Lax controls used correctly) on state-changing POSTs so cross-origin attackers cannot forge a valid request. The token binds the POST to the real admin UI session beyond mere cookie presence, which browsers attach automatically.
HTML-encoding every string written into the response body addresses XSS, not CSRF request forgery—wrong threat class for a forged admin POST. Switching all reads and writes to parameterized SQL mitigates SQLi, not cross-origin form submissions. Confirming only that a session cookie exists, without validating a request-specific token, fails because cookies are sent automatically on cross-site POSTs—the core CSRF condition for cookie-based municipal sessions.
Exam caveat: SameSite cookies reduce CSRF for many cases but synchronizer or double-submit tokens remain the classic exam answer; safe GETs should not mutate state. XSS can steal CSRF tokens, so fix XSS as well when reviewing clerk admin tools.
Operational check: attempt a cross-origin POST without the CSRF token and confirm rejection; repeat with a valid token from the admin form and confirm the state change succeeds only then.