A typical web authentication workflow looks like this:

  1. User provides their credentials.
  2. Server validates credentials.
  3. If credentials are valid
    • Server generates a token.
    • Server keeps this token.
    • Server responds to the login with this token.
  4. Browser stores token.
  5. Browser makes requests with token.
  6. Server validates token and responds accordingly.

Normally, this token is stored in a cookie. The presence and validity of the token in a request lets the server know if the client making the request is authenticated. No token, no entry, which is effectively the same as not being logged in. So...

  • Can I just log out by wiping cookies instead of hitting logout?
  • What are the issues of just wiping cookies versus clicking the logout button?
  • 8
    Auth tokens may also be kept in sessionStorage or localStorage. I assume you intend to delete that as well?
    – meriton
    Commented Jun 1, 2019 at 21:26
  • 3
    @meriton Yes, erasing the token from the client wherever it's stored, without using a site's logout button.
    – Joseph
    Commented Jun 1, 2019 at 22:13
  • 2
    Why not do both? For the reasons listed in @Ghedipunk’s answer, you could invalidate the session on the server side by logging out and then clear your cookies for good measure.
    – dalearn
    Commented Jun 2, 2019 at 11:20
  • There's nothing that "guarantees" you that a given web application will behave sanely when you delete your cookies/storage. Maybe a bunch of vital logic is executed when you use the logout feature. That would be a really shitty web app, and they should have really seen such an obvious use-case coming.
    – Alexander
    Commented Jun 3, 2019 at 15:27

5 Answers 5


Can I just log out by wiping cookies instead of hitting logout?

Frequently yes, for the reasons you supplied in your question: Without the session token in your cookies, a typical web application won't know who you are.

What are the issues of just wiping cookies versus clicking the logout button?

Web applications that manage authentication following the OWASP session management guidelines will invalidate the session on the server side when you log out explicitly. If you simply discard the cookie with the session token, the session may be subject to session hijacking.

Using door locks as an analogy for those who are not familiar with best practices of developing web applications (thanks to discussion in the comments):

Your account can be seen as a room in a building. When you log in, the building's owner creates a door and puts an automatic lock on it, so that only you can enter. Your session token is your key, and is typically stored in your browser's cookies, but can be stored in other places.

Discarding your token by deleting your cookies, clearing cache, etc., is simply destroying your copy of the key.

Explicitly logging off is asking the building owner to brick up the doorway. There's nothing guaranteeing that they'll secure your account, but as the user, you're explicitly making your wishes known.

There are various ways that an attacker can get a copy of your key, known as session hijacking, that are the responsibility of the site owner to mitigate, not the users.

First, the attacker can just guess. If the site generates session keys sequentially, or uses a low entropy pseudorandom generation method, this makes guessing much easier. Sites mitigate this through using high entropy tokens and periodic session recycling. Recycling sessions doesn't prevent access, but it makes it obvious when unauthorized access has been granted.

Second, the attacker can use session fixation: They give you a key before you log in, which you continue to use after you've logged in. Sites mitigate this by explicitly recycling the session when you log in.

Third, a Man-in-the-Middle attack. The attacker can see your key directly. TLS mitigates this. It is possible to decrypt TLS traffic through downgrade attacks, insecure implementations, and zero-day attacks, but these are far outside a user's domain, rare, and zero-day attacks against TLS tend to raise a LOT of noise when they're discovered (Heartbleed, et al).

As a user, your responsibilities are to log off and to hold the site accountable when they take shortcuts with security, much as your responsibility with your car in a public parking lot is to lock your doors. If the door locks are trivially bypassed, then its the manufacturer's fault, not yours.

  • 19
    Answer is true, but there are some session management systems that do not store session state server-side, instead saving it in a cookie in a cryptographically-safe way. So even logging out on the server does not render the cookie useless. Commented Jun 1, 2019 at 15:24
  • And sometimes logging out does not invalidate a token. Some servers retain the token after logout in case multiple devices owned by the user are using/sharing the same token. I seem to recall one of the OpenStack web components did that (I think it was Laravel, but maybe it was another front-end). The recommendation was something like, don't use OpenStack from an internet cafe or other place that offers public access...
    – user29925
    Commented Jun 2, 2019 at 2:16
  • There's also browser identification, such as used by LastPass and many banks, which will have to be repeated every time if cookies are cleared. Commented Jun 2, 2019 at 3:28
  • One reason is listed by Ghedipunk (token still being valid server side). Another thing is that some systems may store token into local storage instead of cookies. e.g. you can see this in OpenShift console. Then clearing cookie will not remove token from your computer. Commented Jun 2, 2019 at 5:32
  • 1
    @TomášZato, I am answering for a typical web application, since that was in the question. I think additional answers with other, non typical session management will be useful, if you're willing to write one.
    – Ghedipunk
    Commented Jun 3, 2019 at 16:13

Some websites make use of non cookie based methods of storing data on a users computer, such as HTML5 local storage and flash player cache that may contain sensitive information.

For example your email client may store your draft email in local storage so that in the event you accidentally refresh the page/close the browser you will be able to resume where you left off. This sensitive data will normally be removed when you click the logout button on a well designed website and would not be removed by merely deleting your cookies.

  • 3
    Only insecure poorly designed applications store sensitive information on the client. That's why your comment is not correct.
    – mentallurg
    Commented Jun 2, 2019 at 22:16
  • 7
    @mentallurg On the other hand, there are really too many of those. Commented Jun 3, 2019 at 0:56
  • @michaelb958: You don't understand the problem. If application stores sensitive data on client side, this is a problem independent on logging out, because for instance connection can be broken and such data will not be deleted any way. So logging out does not make it essentially better. That's why please don't tell that logging out is better than deleting cookies.
    – mentallurg
    Commented Jun 3, 2019 at 1:51
  • 1
    @mentallurg if the connection is “broken” the average user will not be able to log out and will not be able to delete their session cookie(s). So they will be logged in when the computer is reconnected to the internet. Commented Jun 3, 2019 at 1:53
  • 3
    @mentallurg "Even if there is a single case when your approach doesn't work, your solution is wrong." I don't see why you think this is this case. Mohammad Ali is simply stating that logging out explicitly is better because it works more often than the proposed alternative, not that it works every time. If you need an approach to work for "every single use case" else it's flawed, then you might as well suggest that OP doesn't even bother logging out since there is always a non-zero chance the logout functionality doesn't work.
    – DasBeasto
    Commented Jun 3, 2019 at 17:18

Can I just log out by wiping cookies instead of hitting logout?

Yes, since the web application uses cookies to uniquely identify you,deleting cookies will log you out.

What are the issues of just wiping cookies versus clicking the logout button?

The logout button serves a special purpose in that it sends a request to delete the session and returns a response to delete the cookie in your browser as well. If you don't send a request to delete the session then the session still remains alive server side. Sessions do have a maximum lifetime and will be deleted by the garbage collector eventually.

  • 10
    As explained by Ghedipunk above, explicit logouts are used to prevent session/cookie hijacking. Especially on shared computers, there may be software to record all cookies made, so that even when people clear cookies (or close an incognito window) those cookies are maliciously kept. Explicitly logging out invalidates these cookies, so even if they were recorded, they can not be replayed to the server for authentication.
    – QuickishFM
    Commented Jun 1, 2019 at 16:59
  • 1
    "Since the web application uses cookies to uniquely identify you,deleting cookies will log you out." - I don't believe this is correct. Deleting a cookies is a client side action. The server knows nothing about a client removing a file. You have to explicitly tell the server to log you out.
    – user29925
    Commented Jun 2, 2019 at 2:19
  • @jww which is what i wrote here "The logout button severs a special purpose that it sends a request to delete the session and returns a response to delete the cookie in your browser as well"
    – yeah_well
    Commented Jun 2, 2019 at 5:45

There are no risks.

Someone has pointed out that it might increase the risk of session hijacking. But that is not true. If the application has session (is stateful), this session has a timeout. And after session expires there is nothing to hijack. If session is active, then the chances to hijack a session of an active user are are almost the same as for a "orphaned" session. Taking into account tools that quickly detect multiple request with invalid session IDs of somebody who tries to brute force session ID, there is no additional risk on the server side.

On the client side there can be more risk in case of log out than in case of deleting cookies. Log out invalidates session, but can keep some other sensitive data. For instance, when you log out from Google Mail, your user name is still kept in cookies; and when you go to Google Mail, you will see your user name prefilled. First, may be you don't want anybody behind your shoulder to see this user ID. Second, if in hurry, you may log in into a wrong account (of your multiple accounts). Similar problems may happen in other applications. Where as when you delete cookies your are sure there is nothing kept in your browser what you are not aware of; you will not be surprised by any data stored in cookies. So actually in case of log out the risk of negative surprises is higher than in case of deleting cookies. I have to say that when one deletes cookies one should also consider deleting local storage.

A single disadvantage that I see in case of deleting cookies is that server will use slightly more resources to keep session data until session is time out. But the question in OP is about risks for the client. So there are no risks. And now days the most applications have no state on the server; logging out means in such case just invalidating the token; there are often no resources blocked by session. So even "orphaned" session doesn't take any additional resources.

One more aspect to consider: Depending on application and on internet connection, logging out may take considerable time, a couple of seconds. Where as deleting cookies (and local storage) happens immediately and does not depend on server and on internet connection.

May be somebody will find other important points that I overlooked and will criticize my point of view. That's fine. I just wanted to encourage users not to follow any rules blindly, but to think about what is happening actually.

  • 1
    I'd absolutely agree that the risks are very minimal, but not that there are no risks. By default, PHP stores session data in the server's /tmp directory without any explicit expiration system other than the regular culling of files that had not been recently accessed. I've seen the cron job configured to be nightly, weekly, monthly, and even disabled. -- Just a minor nitpick, though. I find security -- and paranoia in general -- easier to deal with if I question any absolute statement.
    – Ghedipunk
    Commented Jun 4, 2019 at 17:24

There is also the risk that you forget the password, although this is more likely to be an issue for someone who only rarely needs it not every session they go to a particular site.

  • 9
    I would consider not being able to access the site when the user has forgotten the password (even if this is the user) a security feature .. Commented Jun 2, 2019 at 1:59

You must log in to answer this question.

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