I have found a lot of information on creating sessions, but I am still a little confused about working with them.

For one, I am not sure how to handle updating the session on use. My understanding is that you will still have an absolute max lifespan, but it is OK to refresh the session on use? So if the user used the site regularly, the site would continue to work over many individual lifespans of the cookie/session? When this happens do I generate a new session, and invalidate the old one? Presumably I would I do this only when the session is old enough, so that I am not doing it every single site interaction?

I think ideally I would want something like:
Sessions last 10 days
When sessions are over ~4 days old, using them creates a new session with a new session id and the old one is invalidated.

Is this correct for a low security website?

Then if I need more security I assume I can just store the last time the user credentials were verified and if that was over 5~15 minutes ago, force the user to re-login to perform the action?

Finally. I am not sure how to handle absolute max lifetime when dealing with long lived sessions. All the simple implementations I can think of allow for the possibility of the session expiring on a legitimate user during use. I think a good method would probably use some sort of idle timer? Real users will not use the site every minute for a week straight, so we can say, have a absolute lifespan of 6 months. When a month is left on the absolute lifespan require a login if the session has been idle for longer than a 12 hours, if less than a week is left do the same for 15 minutes.

But if I am already tracking session use, should I then use it to detect potential bots? Something like, if a session is activated every hour for 24 hour, do I ask for credentials again?

1 Answer 1


There is no universally “correct” way of implementing session expiration. You'll have to find a reasonable balance between security and usability for the specific application.

The reason why the session duration matters at all for security is because sessions can be hijacked (e.g., through leaked IDs or physical access to the device) and misused (e.g., through cross-site request forgery or cross-site scripting). To make successful attacks less likely, sessions should ideally be limited to the time frame when the user actually interacts with the application. Of course you cannot always predict this time precisely, but it's possible to at least approximate it.

  • An idle timer is a good idea. Depending on the application, there's going to be a typical usage pattern. If users interact with the application a lot (e.g., one activity every few seconds on average), then make the timer expire when you haven't seen a new activity for something like 15 minutes. If users spend a lot of time just looking at the screen (e.g., to read longer texts), then increase this time to several hours. If possible, measure the activity both server-side (received HTTP requests) and client-side (like JavaScript scroll events), because this will give you more accurate data.
  • Setting an absolute lifetime is also a good idea to prevent users from extending the session arbitrarily. For example, invalidate the session forcefully after a few days, regardless of activity. 6 months seems a bit extreme.
  • To interrupt the user as little as possible, regularly save any inputs and bring them back to the current page after they've logged in again.
  • If there should be long-running sessions, make the user explicitly request them (e.g., through a remember-me checkbox). Separate the long-running sessions from the default ones and harden their settings (the server should not store the IDs as plaintext, and the cookie parameters should be as restrictive as possible to prevent CSRF attacks).
  • If the user requests particularly sensitive content or wants to perform a critical action, force them to re-authenticate if they haven't logged in recently. For example, in an online shop, just browsing through articles isn't critical and can be covered with the standard session mechanism, but when the user wants to change or view their personal data, or if they start the checkout process, you want to make sure this is actually the legitimate user, not an attacker who has hijacked the session.
  • Encourage users to explicitly log out when they're done. For example, if the session has been terminated automatically, show a short message and point to the log-out button. I've seen e-mail services do this, and while it may seem a bit silly at first, it at least makes people aware there is a log-out button.
  • To additionally protect the sessions, make sure to use HTTPS consistently, prevent XSS attacks and implement CSRF protection. For XSS protection, use a template engine which automatically HTML-escapes input, and take advantage of Content Security Policy. For CSRF protection, the Synchronizer Token Pattern, the __Host prefix and the SameSite attribute are particularly helpful.

Bot detection is a separate issue. I wouldn't worry about this when you're still implementing the basic session mechanism.

You must log in to answer this question.

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