CSRF protection for sensitive account changes

Context

An account settings area in a PHP application, reviewed under written authorisation in a staging environment.

Scope

Profile update, email change and password change endpoints, plus the session cookie configuration supporting them.

Vulnerability

State-changing POST requests were accepted without an anti-CSRF token, and the session cookie had no SameSite attribute, so a cross-site form submission executed with the victim's session.

Root cause

CSRF middleware existed but the settings routes had been registered outside the protected route group during a refactor, and no test asserted the protection.

Impact

A victim visiting an attacker-controlled page while logged in could have their account email changed, enabling a password reset takeover. Rated Medium because it needed user interaction, but the outcome was account takeover.

Remediation

• Returned the settings routes to the CSRF-protected group and removed the ability to register unprotected web routes.
• Set SameSite=Lax, Secure and HttpOnly on the session cookie.
• Required current-password re-authentication for email and password changes.
• Sent a notification to the previous address on any email change, with a revocation link.
• Added tests asserting that a POST without a valid token returns 419 for every state-changing route.

Retesting

Retesting submitted the original cross-origin form, a token from another session, an expired token and a request with the token omitted entirely. All were rejected. Legitimate changes continued to work, and the notification e-mail was observed on the previous address.

Lessons

• Protection applied by route group is only as reliable as the discipline of route registration; assert it in tests.
• CSRF defences pair well with re-authentication for high-value actions.
• Notifying the old address is what turns a silent takeover into a detected one.