A library account settings page changes email via session-cookie authenticated POST with no anti-CSRF token or equivalent defense. What vulnerability class fits?
Select an answer to reveal the explanation.
Short Explanation
If the clerk trusts every letter that arrives with your cookie crumbs, a forged form can change your address. CSRF rides authenticated sessions into state-changing POSTs. Tokens or equivalent checks break that trick.
Full Explanation
CSRF fits when state-changing cookie-authenticated requests lack anti-forgery protections. A library account settings page that changes email via session-cookie POST without an anti-CSRF token (or equivalent) can be triggered by a malicious site while a patron’s browser is authenticated—potentially hijacking account recovery email for library services.
SQL injection in catalog search and missing SPF are different classes. SameSite=Strict can mitigate some CSRF cases but is not automatically present or sufficient in every browser/legacy scenario; the stem describes missing anti-CSRF defenses, not a perfected SameSite deployment.
Exam caveat: defense-in-depth pairs CSRF tokens/SameSite/re-auth for sensitive account changes. CPTS CSRF questions focus on cookie-auth state changes without request authenticity checks.
Operational check: attempt a cross-site forged email-change request in a lab browser session within RoE, add anti-CSRF tokens and consider SameSite plus re-authentication for email changes, then retest the library settings flow. Sensitive library account changes should require recent re-authentication in addition to CSRF tokens, reducing impact of stolen session cookies.