I am making a web application in Django which generates and includes CSRF tokens for sessions (a Django session can be anonymous or a registered user). Should I keep CSRF protection to the controllers handling login and logout action?

  • 5
    Sites like http://superlogout.com/ actually use the fact that most sites don't have logout CSRF. (before clicking the link: it will call out to major sites, like GMail or EBay and call the appropriate logout endpoint to log you out)
    – SztupY
    Apr 2, 2015 at 13:16
  • Here's a practical example that uses CSRF on the login and logout functions of Uber to exploit a XSS vulnerability.
    – Sjoerd
    Mar 23, 2016 at 15:42

6 Answers 6


Possibly you should protect against Login CSRF. Without this protection an attacker can effectively reverse a CSRF attack. Rather than the victim being logged in to their own account and the attacker tries to ride the session by making requests to the site using the victim's cookies, they will be logging into the site under the attacker's credentials allowing the attacker to effectively hijack requests to the domain that the victim thought were anonymous or were under their own account and then sending it to the attacker's account. Of course whether this is relevant to your particular site or not depends on the nature of your site and whether something like this is advantageous to an attacker. An example is a Login CSRF attack on a search engine so the attacker can see the terms being searched for as they are logged under the attacker's account instead of the victim's.

The main targets for this type of attack is where authenticated actions can take place outside of the main application itself. e.g. from a browser plugin or widget embedded on another site. This is because these actions will be authenticated through the use of cookies, and if an attacker has you logged in as them each action will be recorded in their account.

You should also protect your logout mechanism against CSRF. At first it seems that all an attacker can do is logout the user, which would be annoying at worst. However, if you combine this with a phishing attack, the attacker may be able to entice the victim to re-login in using their own form and then capture the credentials. See here for a recent example - LostPass.

  • 3
    Also: Depending on what your app does and/or how this logout can be triggered, this could become a DoS that chases customers away. Jan 1, 2016 at 7:07
  • 4
    @SilverlightFox : Actually adding<img src="https://accounts.google.com/Logout">to a page will log you out of every google services. So If they let this, it’s certainly because csrf for logging out isn’t a significant threat. Jul 3, 2016 at 22:17
  • @SilverlightFox Are you saying: The victim logins with the attacker credentials? So the attacker made logged in the victim in his own bank account? Seems like a unique attack...
    – Alboz
    Jul 14, 2017 at 9:21
  • @Alboz: It might be possible in a payment scenario. Say there was a "generate payment link" function in a widget where you can grab a link to your payment provider's site to enable people to deposit money by sending them the link. If the attacker logged you in as them then every time you generated a link and it was used it would deposit money in the attacker's account instead of yours. Jul 14, 2017 at 10:23
  • @SilverlightFox that's a very creative mental scenario but completely not realistic and impossible as in that case there would be other protections in place. Anyway what I'm trying to say is that this is only needed for specific type of websites. Not every web app needs to care about reverse CSRF on login... The only case I've heard is Youtube and the attacker used it to just see what videos the victim watched... People are reading your answer and thinking that even private web apps with no defense for reverse CSRF are at risk.. which is not true.
    – Alboz
    Jul 14, 2017 at 11:57

CSRF Protection on Logout is a must !

Why? Assume the following scenario:

  1. You're on a trading page and prepare a buying order for e.g. 1000 Daimlers on an Exchange XETRA.
  2. Until you are preparing the order, somebody, who knows that you are logged on https://anybrokerpage.com/ , sends a phishing link to you. e.g. https://anybrokerpage.com/logout
  3. By clicking the link, you are logged out and the order is perhaps not finished.
  4. After logging in again, you recognize that the price for the 1000 Daimlers is higher than a minute before you logged out by this phishing link.
  5. Now you have to order a higher price.

A CSRF Token on the logout would have prevented this mess.

  • 3
    You don't even need to click the link. All the "attacker" need is some site you visit which allows user to include images from external domains (forum, other forms of social media sites FE.). Viewing the "image" https://anybrokerpage.com/logout would log you out. Feb 22, 2016 at 18:07
  • 2
    This seems like an argument for POST logout, but not necessarily a CSRF-protected logout.
    – jwhitlock
    Apr 30, 2018 at 14:02
  • 4
    Really strange argument for CSRF in my opinion. The whole Attack in this case was performed by someone to divert your attention, caused you to re-login, waste time and buy on a higher price??? Imagine someone attempting that same plot, only this time around, when you relogin, the price dropped (due to a newly found Diamond Mine in South African ) by 50%. God bless the hacker ! May 14, 2019 at 9:05

Login? Yes. Logout? No.

Why login? There is this funny CSRF login attack, where the attacker logs in the victim under aa attacker-controlled account, and then can "gain control over content created by the victim while logged in under that account". The impact is pretty lame IMO, but they started to see this as a problem now that more juicy attack vectors are gone. ;-)

Why not logout? There is no security impact. The best one can do is to log someone out of the system, which causes annoyance at most.

EDIT: There is no security impact in logout CSRF attack by itself. There may be cases when this may be used in a multi-stage attack to first log someone out, then prompt them to log in on a spoofed page.

  • 1
    If you implement CSRF correctly you shouldn't even have to protect each field seperately. It should be part of your framework. Jul 9, 2014 at 7:53
  • 1
    Surely you meant "each form"? Jul 9, 2014 at 8:03
  • Yep, that's what I meant Jul 9, 2014 at 8:03
  • Could you elaborate on "gain control over content created by the victim"? Jul 9, 2014 at 8:47
  • 3
    Suppose you are the attacker. You create an account on a vulnerable system and thus, obviously, can access the account and anything related to it. Then you conduct the login CSRF attack against the victim. Suppose the victim creates a "secret" document while logged in under the controlled account and stores it there. Then, you automatically have access to the document by virtue of having access to the account he created. The attack is weak and requires quite some preparations, but looks somewhat plausible. Jul 9, 2014 at 9:00

Logout and login CSRF is actually very exploitable.

If you find a way to get a permanent private/self XSS (such as an unsecured private field like in user preferences) you can force log out the victim, login in with your account which has the self XSS applied, and then execute some code to make a phishing attack except it's on the correct domain with a valid SSL cert. If the user logs in (or has auto fill which would allow you to steal their credentials before they even hit submit AND then auto login for them so they may just see their page flash white and then they'll be where they expect) you now have their password and a same origin execution. Now just run some exploit persistence in their private settings and now you've got permanent remote JS execution on the users account.

This allows very major attacks especially since many developers don't both with HTML injection exploits on private fields because only the user should be able to see that and they have no reason to execute code against themselves. A login logout CSRF exploit let's you perform same origin phishing and if they have same origin iframes enabled you can also embed the login page full screen and then execute whatever code you want inside the seemingly legit iframe.

Any of the bugs alone range from useless to annoying at best but if you have these two (and it's best to always assume you do) an attacker can hijack a users account with just one nasty ad.


CSRF for login generally yes but does depend on your application. an attacker can log you into a malicious account eg in Google and then monitor all your site visits.

CSRF for logout - yes absolutely can prevent DOS


Logout CSRF can be useful when chaining with other exploits.

For example, there is a web application I am testing on, which use WAF for more protection. This website have a redirect loop that pointing to their login page. Therefore, when user access the redirect loop, their browser will call /login page many times and make WAF locks them from accessing /login page for 1 hour. It does not matter because they already logged in. However, if I use logout CSRF to kick them out after WAF locked them. Then it is a problem, and I did exactly that.

You must log in to answer this question.

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