I am developing my site using server side sessions using redis as backend for saving the session.

Now the issue which is bothering me is of user leaving the website without logging out. I mean user simply closes the browser which causes the cookie to be deleted.

Now session of that user still exists on the server and will not be used again as new login requires creating a new session due to security reasons. To avoid the case where hacker steals the old cookie and use it after user login again with same old session id.

In essence user leaves the website without explicitly logging out and his session will be deleted after certain time limit of inaccessibility. I am thinking time limit of 30-60 minutes. Also with every new request from user his cookie will also be updated to keep track of when the user last time accessed the site.

But nowadays, people let site remain open for long time without accessing it. For example users open facebook and gmail in new tabs and forget about them for 2-3 hours and still they are not asked to login again.

Is letting a 2-3 hours old cooke access the session secure? My concern is someone steals user cookie and use it 2-3 hours later.

Thinking on this topic has also forced me to question how facebook manages security if user can use a session where they are not accessing it for long periods of time and still they remain logged in. Or is it not secure for me to keep logged in when am not accessing the site session for longer period of time?

It can be the case also there is some pinging mechanism using which sites keep track of user having their site open in a browser and when browser closes they are notified and can work accordingly.

My website is a social network and needs all those security and usage features which a social network may need.

I am new to web security and web development in general and may be the case where my above questions may seem a little basic. If you feel that is the case kindly point to some good reference where I can read and find answers to my question.

3 Answers 3


Yes, for most sites it is fine to leave a session valid for hours (say, 24 hours).

As with any security question, you start by asking: what resources am I trying to protect? What is the threat model? What am I trying to defend against?

In this case, you are worried that an attacker might be able to "steal" a session cookie. So the next question you should ask yourself is: how could an attacker steal a session cookie, and how do limits on the lifetime of the session affect that risk?

One way an attacker can steal a session cookie is if the user is logging in from a shared computer (e.g., at a cybercafe or library; or just a computer shared with roommates). In that case, if the user does not log out of your site and leaves the browser up and running, the attacker merely needs to sit down in front of the computer and start using the browser. The lifetime of the session affects the scope of the risk and the time window of vulnerability. If you expire a session 1 hour after last activity, then an attacker would have to sit down in front of the user's machine within 1 hour after the user stops using the site. If you expire a session 24 hours after last activity, the attacker has 24 hours. Overall, I think this risk is a relatively modest one: hopefully users at a cybercafe will shut down the browser, and hopefully people who live in shared housing can trust their roommates at least to some degree (otherwise they've got bigger problems).

Another way an attacker can steal a session cookie is by eavesdropping upon a cookie as it is transmitted in the clear, say over HTTP while the user is connected via a wireless network. Here session expiration times do not affect the risk at all. The best way to defend against this threat is to use HTTPS sitewide and set the secure flag on all cookies.

A third way an attacker can steal a session cookie is by planting malware or spyware on the poor user's machine. But if an attacker manages to do that, you are totally hosed, and session inactivity limits won't save you from bad stuff happening. So this one shouldn't influence your inactivity limits, either.

Bottom line: For most web sites, a session lifetime of 24 hours (or at least a few hours) should be fine. For web sites where you expect users to stay logged on, like Facebook, you might allow a session lifetime that is much longer. For security- or privacy-critical sites, like online banking or access to sensitive medical records, I would suggest a very inactivity timer: maybe 15 minutes.

P.S. It is possible to track when a user closes a tab, using Javascript, but I'm not sure whether this will make a big enough security difference to be worth implementing. The security risk is not too different in the case where the user has left your site open in some other tab and forgotten about it vs. where the user has closed your site but left the browser open. A simpler way to handle this is simply that the server keeps track of the last time that it received a HTTP request on this session, and once an expiry time (say, 24 hours) passes with no activity (i.e., no HTTP requests), the server deletes the session.


It's a tradeoff between usability and security. Internet banking will close connection after a very short time of inactivity, and the sites you mentionated (gmail, facebook, etc) will not logout because their users would be upset to login every time.

Your decision will be much more based in this security x making users unhappy.

Technology about it: I'm not sure that a javascript would capture all movements the user makes in his computer, even if they are outside your web-page.

  • 1
    I thought so too. So maybe I can check user agent and other details about the incoming request and if I see some anomaly I can ask user to login again otherwise I let the usability rule.
    – codecool
    Mar 5, 2012 at 14:09

You can do what Google, Facebook etc. do (and the reason why people keep the page open): add some sort of updating widget using AJAX.

If the page has been left open, then the AJAX widget will run and will make a request at intervals, keeping the session current.

If the user has logged out, the session begins aging and can be purged after some time. In theory, after twice the widget interval has expired, the browser ought to be certifiably dead: if it was alive, the widget would have callled home (but the user might want to reopen the browser, or perhaps has restarted it for updates, or might have suffered a temporary loss of connectivity (especially if mobile); so shorten the garbage collection time at your peril).

Of course this cannot address the scenario where the user forgets the page open. In this scenario the widget is actually counterproductive because it will keep the session alive and warm for whatever passersby to use at will. You will need some sort of inactivity policy in addition to the session aging, and will have to communicate it to your users.

There are ways to detect user's activity, but none completely reliable. I'd keep things simple: if security is paramount then no widget and inactivity timeout. If usability is paramount then go the widget way, and possibly add an "idle logout" to close the session if no other activity except the widget's has been detected in a reasonable while.

You must log in to answer this question.

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