Session Cookie Expiry Calculator

Most security audits fail because of something that seems simple: a session cookie lives longer than it should. It’s the bug you already know about. You get up from your desk to grab lunch and when you come back three hours later you’re still logged in, this is great, until someone steals a token during transmission or sits down at your computer.

Yet expiration is generaly treated as an afterthought by most team. They pull some number out of thin air with nothing modeled around real-world risk exposure. The calculator above removes the guesswork behind a sensible policy rooted on device trust, idle time and absolute limits.

How to Set Safe Login Time Limits

To start with, there are two distinct setting: absolute lifetime and idle timeout. They do two different things. A tab that’s been abandoned is handled by idle timeout which kicks in if the user stops typing or clicking around. Absolute lifetime is more like a hard stop, it will force the user to reauthenticate even though they’re still active.

Setting an absolute limit of, say, thirty days with a fifteen-minute idle timeout mean you’ve just opened up a huge security hole for the user who leaves his browser on overnight. The calculator calculates these variables and shows which one triggers expiration first so users won’t fall into trap of having a very tight idle window but a long absolute one.

You should also consider the remember-me functionality. This cuts down on user login pain; nobody loves having to log in over and over again. But it massively increases your liability window. Where a typical session cookie might last just one hour, a remember-me token could stick around for months or weeks at a time. And if someone manages to get their hands on that token, they’ve got a long runway.

Banking platforms typically turns off this option completely due to the higher risk. Community forum apps may be able to get away with longer windows, since cost of compromise isn’t as high. The tool will ask about your app type and compliance targets here too and tailor its suggestions accordingly, maybe you’re creating a casual blog? Or perhaps a healthcare portal dealing with protected data?

These choices also rely heavily off device trust. You shouldn’t grant nearly as much leeway to a session initiated on a public library computer as you would one on a managed company laptop. When your users often use it from untrusted or shared computers, you should limit both your absolute and idle time limits accordingly. To help with that, the calculator allows you to show the device context and then will recommend stricter limits based off increased ease of session hijack in public environments.

Those windows may just surprise you. How much shorter they’ll have to be different than what you set internally on your intranet.

Cookie flags are another level of protection that is frequently neglected. Adding the Secure and HttpOnly attributes doesn’t alter the duration for which a cookie remains valid, rather they modify which parts of the application is able to read it. A cross-site scripting vulnerability immediately puts your user accounts at risk if a script can read your session ID. Limiting exposure by keeping cookies away from scripts reduces the attack’s blast radius. SameSite settings further reduce the threat of cross-site request forgery. How each flag interacts with your expiry strategy is laid out in the reference table on the page.

Scope matters too, not just when. In addition, think about step-up authentication. Rather than making your users re-authenticate at every brief interval, authenticate them when they do something risky. This includes making a change that affects their account, such as changing a password or trying to export their data. That way you have tight control when it matters, but a smoother workflow most of the time.

This create a smarter security stance and a better user experience. But selecting the proper expiry policy isn’t about discovering the magic number. It’s about balancing the risks against the convenience. You need your users locked out frequently enough to be secure, yet infrequently enough that they don’t give up on using your product.

Begin with the presets and tweak as necessary to suit your audience. Let the numbers do the talking. Try for a system that expires on its own terms before any trouble could of begun.