In this post, there is a paragraph that mentions a scenario where there is no need to validate anti-forgery token in login page:

When is it OK to leave off the anti-forgery token? In general, if the target is a URL, and accessing that URL has no side effects, then you don't need to include anti-forgery token in that URL.

I understand how a CSRF attack works but I am quite lost at this paragraph unfortunately. It says:

  • If the target is a URL
  • If accessing that URL has no side effects

Is there a target that is not URL? and what is an example for a "side effect"?

I have an ASP.NET MVC application that is hosted at a URL such as subdomain.domain.com. My users receive these errors:

“The provided anti-forgery token was meant for a different claims-based user than the current user.”

“The anti-forgery cookie token and form field token do not match.”

“The provided anti-forgery token was meant for user "", but the current user is > "XYZ".”

In other words, my question is that what are the scenarios in which it is okay not to use anti-forgery token in login page?

  • 2
    That's two separate questions: (1) what is a side effect, and (2) when is it OK to not use an anti-forgery token on a login page? Generally when you have two separate questions it is best to ask them separately. – D.W. Feb 21 at 22:15
  • I suppose "non-URL target" refers to anchor (<a>) or button/input with a JS listener that will stop the click propagation: user clicks on a link, but the browser doesn't actually follow the link to a web document (instead, JS listener stops the event and do treatments in the current page) – Xenos Aug 21 at 14:05

Visiting a URL can cause a side effect. For instance, if I'm logged into Amazon, visiting a URL may cause an item to be purchased and shipped to me (one-click buy). That's a side effect. Or, it might log me out, or log me in, or update some settings. Those are side effects, too.

In general, a operation has a side effect if it changes some (persistent) state on the server, or has some persistent observable effect on the world.


CSRF protection is not required when the action performed by the cross site request itself is trivial. But it is ideal to have such a protection for any action which has a persistent aftereffect in the applications context.

For example:

A file upload for configuration files would require an anti-CSRF token where as a simple search query which will only display the information would not (if your application's CORS settings are set right. )

In case of login pages, it wouldn't be required in general unless a failed login action itself would create a persistent change in application's context.

  • 2
    You're neglecting the possibility of a successful login action, using the attacker's credentials (ie login CSRF). – AndrolGenhald Mar 24 at 0:07
  • @AndrolGenhald Even in that case, nothing other than the login action itself would be possible if the application itself is protected against CSRF in post-login actions. – hax Mar 24 at 0:44
  • Doesn't matter, it's still a vulnerability. I go to definitelynotmalicious.com and it uses login csrf to log me in to victimstore.com with an attacker's account; later I go to victimstore.com and buy something using my credit card, and since I expect to buy more stuff in the future I have it save my shipping address and credit card to "my" account. Attacker now has my credit card number and shipping address. – AndrolGenhald Mar 24 at 0:54
  • A bit far fetched but a valid case I agree. If the application you test is if that kind, then it makes sense. – hax Mar 24 at 1:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.