Apparently Random Error: "Antiforgery token validation failed. The antiforgery cookie token and request token do not match."

We’ve been experiencing this problem for several years in a production application on ASP.NET MVC 5 (though similar anti-forgery mechanism to ASP.NET Core). Our application has a few components that are mini-single-page-applications. So, there’s a lot of requests via JavaScript that we do that include anti-forgery protection. We’ve been able to prevent anti-forgery errors by introducing a couple of changes:

1. Disable HTTP caching on HTML views that are returned to the browser - If the page was cached, the user could hit back and be served a page with a state form token that no longer matches the cookie. Our application is behind authentication and we do caching at many other levels (HTML fragments/views, data layers, etc) so full HTTP caching of a page doesn’t make sense for us anyways.
2. Detect logging in/out of multiple tabs and clearing cookies in the same browser session - If a user had a stale anti-forger token on a page but logged out with a separate tab, cleared their cookies, and logged back in with another tab, they had the possibility of using that old tab with the stale anti-forgery token. We prevented this from happening by allowing the tabs to communicate when loaded (e.g. via localStorage session events or using the Broadcast Channel API) and show a message on the “stale” tab. A lot of sites do this similar pattern (e.g. GitHub, AWS Console, etc). This reduced a large majority of our problems.
3. Prevent form submission double-clicking - This helped anti-forgery errors caused by double-form submissions on pages like our login if the anti-forgery token happened to be re-generated once logged in.

Although this fixed most of our problems, we still have had consistent anti-forgery problems from some of our users. We have a heartbeat-like request that sends useful information for aggregating/reporting later on in the user interface. This heartbeat-like request would continuously fail for certain users meaning that their data was lost and couldn’t be reported on. Thankfully, the anti-forgery error was transparent to them but it meant a discrepancy in data for reporting.

In a recent investigation back into this problem, I found some interesting revelation in our logs:

1. When the specific users were having problems some of their heartbeat-like requests were being accepted and validated by our servers but some were failing with anti-forgery mismatch exceptions.
2. When the users that experienced anti-forgery problems first started work in the day, our logs would show concurrent requests from them with the referrer empty.

Here’s what this is caused by:

1. The user logs into the application with an authentication cookie.
2. The user changes their browser setting to Open a specific page or set of pages on startup (e.g. in Chrome).
3. They set multiple pages of our application in that list (e.g. /apples and /bananas).
4. They’re done for the day and close their browser.
5. The __RequestVerificationToken cookie is cleared because it’s only alive for as long as the browser’s session.
6. The .ASPXAUTH cookie is not cleared because it has a default expiration of 1 year.
7. The next time the user launches their browser, /apples and /bananas are launched concurrently in our app. This could also be accomplished just by doing something like middle-clicking on a tab more than once, but the pattern seems to fit since this causes the referrer to be empty. Both of those pages render a form with the anti-forgery token (e.g. @Html.AntiForgeryToken()).
8. Both requests generate a new __RequestVerificationToken cookie and send it as part of the response because the request does not have a __RequestVerificationToken. When the form’s token is generated during the request, it’s for the unique cookie token per-request.
9. The browser chooses the last cookie to be saved, thus causing the first tab’s form token to be invalidated because it no longer matches the cookie when the tab was loaded. When our heartbeat-like requests are sent from the “bad” tab, anti-forgery exceptions are thrown server-side.

I have some ideas to work around this, though I haven’t fully thought them through:

1. Seed the cookie token based on the user’s current authentication context (e.g. in our case their internal user session id in our database). Anti-forgery (at least in MVC 5) doesn’t have a way to hook into this.
2. Change the anti-forgery token to be the length of the user’s authentication session when it’s first created. This would prevent it from being cleared in the first place. I’m not a security expert, so I’m not sure if this is a good idea.
3. Somehow detect the form anti-forgery token changes per-tab like we do with stale sessions. Obviously, the form tokens are always unique per-form… so I’m not sure how detecting a “change” could help here.
4. Use a mechanism outside of our web servers (e.g. Redis) to prevent generating the anti-forgery token more than once. This seems expensive because there’s no way to hook into when ASP.NET generates a new anti-forgery token.

Does anyone else have any ideas on how we could solve this problem? @wessleym I’m not entirely sure if any of this can help solve your problem but I hope it may be able to provide some insight.

If it’s worth something, iv’e been facing this issue since ASP.NET MVC 5. As it is described it happens 1 on 1000 times apparently random. No matter how hard I try, I still cannot reproduce this behaviour