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.
    Commented Feb 21, 2019 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
    Commented Aug 21, 2019 at 14:05
  • I think side effect here means non-idempotent: stackoverflow.com/questions/1077412/… Commented Jan 13, 2021 at 11:43

3 Answers 3


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.

  • Just for anyone reading, "side effect" can be thought of as non-idempotency. Commented Jan 18, 2021 at 9:21
  • 1
    @DavidKlempfner, I think they're closely related, but I don't think it's exactly identical. Consider a missile silo that has exactly one missile in it. The command "Launch all missiles!" is an idempotent command (doing it twice has the same effect as doing it once, as after you've done it once there are no more missiles remaining); but the command does have a side effect. You need an anti-forgery token (CSRF token) for that kind of command, too.
    – D.W.
    Commented Jan 18, 2021 at 20:07
  • Good point, didn't think of that. Commented Jan 19, 2021 at 1:23

My understanding is the real issue is cookies that store the auth credentials because the browser automatically sends it to the URL. If you don't use cookies and don't have some script that always sends auth data on request, you don't need the anti-forgery token. It doesn't make sense to ever use it if you think about it. If you just use a JWT token or some other token (a unique string), it is the same thing as sending an anti-forgery token because ultimately that is what the anti-forgery token is. You should also use SSL or TLS.

General rule: don't use cookies. They have been proven time and time again to be a bad design pattern.

  • Ok, but your http(s) server gets the requests, from multiple clients, simultaneously. Their IP can change between the requests, and multiple clients can come from the same IP. How do you identify on a secure way, to which client/user an actually given request belongs?
    – peterh
    Commented Feb 20, 2020 at 11:13
  • Your question is about HTTPS and if it is secure. HTTPS protects from a man in the middle attack by protecting the connection. That is why it is required for protecting the token (to prevent others from knowing what your token is).
    – kevin
    Commented Feb 21, 2020 at 16:04

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.

  • 3
    You're neglecting the possibility of a successful login action, using the attacker's credentials (ie login CSRF). Commented Mar 24, 2019 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
    Commented Mar 24, 2019 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. Commented Mar 24, 2019 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
    Commented Mar 24, 2019 at 1:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .