In the previous articles, we hardened the login: constant timing, progressive lockout, no existence leaks. The user is authenticated. Now the question is: how do you protect the actions they take once logged in?
CSRF. The topic everyone thinks they've mastered because they put a token in a hidden field in 2015. Except the double-submit cookie — the pattern found in 80% of implementations — has weaknesses most developers ignore.
Double-submit cookie: the pattern and its limits
Double-submit cookie works like this: the server sets a cookie csrf_token=abc123, the form sends the same token in a hidden field, the server compares both. If an attacker can't read the domain's cookies, they can't forge the request.
The problem: the attacker doesn't need to read the cookie. They need to set it. And in several scenarios, that's possible:
