I need to create a session cookie using JavaScript (for more info see question). I'm wondering what should the expiry date be? I'm guessing it's the browsing session, so if I don't set an expiration date this will be used as the default, right? This session would be used to validate a logged on user. So does it depend on how long I want users to stay logged in before automatically logging them off (if yes what's a good time, or should it stll be the browsing session?)?

3 Answers 3


I'm guessing it's the browsing session, so if I don't set an expiration date this will be used as the default, right?

Yes. Unless you have a particular need for sessions to survive a browser restart, omit the expires parameter so that the cookie is browser-session-only and not persisted to disc.

does it depend on how long I want users to stay logged in before automatically logging them off

That is governed by your actual session expiry time, which should be implemented on the server-side alone. If you do use an expires time you would generally want it to be at least as long as the server-side timeout, but you shouldn't rely on the browser honouring that expires as your method of ensuring old sessions are unreachable.

Generally, session-only (no-expires) cookies are used for session-tracking, with timeout happening on the server side. If a request is made with an unrecognised or missing cookie, then likely the session has expired at the server side, the browser has been closed at the client side, or both, and you should direct the user to start a new session.

Typically there will be a session management tool included in whatever your web framework is on the server-side that will work this out for you by sending the appropriate Set-Cookie headers on an HTTP response (either the initial HTML page, or an XMLHttpRequest response). Whilst you could reimplement session management yourself using only JavaScript, passed parameters and, say, localStorage as an alternative to cookies, there doesn't seem to be that much to win by reinventing that wheel.

  • 2
    erm, not exactly. Both Firefox and Chrome have the ability to resume an automatically saved state (browser session) at start up which includes session cookies (cookies without an expiration date) - so they can be persisted on non-volatile storage.
    – symcbean
    Aug 24, 2017 at 19:28

My recommendation would be: "Don't create the authentication cookie using JavaScript." A cookie identifying an authenticated session should be marked wit the HttpOnly flag to help mitigate XSS attacks, and so must be created by the server and sent with the response, not created on the client.

That bit of advice aside, your assumption is mostly correct. If there is no expiry set on the cookie, then it is a session cookie and will live as long as the browser is open, and the sessionid is valid. If the server expires the authenticated sessions periodically, then the cookie will no longer be attached to a session on the server and will therefore be essentially null.

To your second question, if you wish to specify a maximum amount of time a user is logged in before needing to re-authenticate, it's usually done with a rolling expiry, where the expiration time is updated with each request to be x minutes from now, so active user sessions aren't forcibly expired, only idle sessions where a user hasn't made a new request in the last x minutes. The most secure way to do this is to tie the value of the cookie to a session on the server that expires on time, which can't be interfered with by the user. The expiry on the cookie is not sufficient, as it can be changed by the client. If you need to store a session expiration client side, it needs to be encrypted in the value of the cookie, so again needs to be created server-side, not by JavaScript, because the server must be the only place the value can be decrypted in order for it to be secure.

And lastly to your third question, what is an appropriate amount of time before expiring a session? It depends entirely on your application. Financial applications often have very short timeouts of five or ten minutes. Many applications have a more traditional default time out of 20 or 30 minutes. If the workflow of your app requires extensive amount of time on a page without refreshing, even longer may be in order. I don't know that it's terribly important in any case, unless your application has specific security needs.

  • Hold on a second. HOLD ON A SECOND! "Don't create the authentication cookie using JavaScript." Why? A user has control over their cookies regardless if it was created by local JavaScript or a client side script (PHP in my case). Note the session itself is created by the server, on the server. I'd really like to be clear on this before I bust my ass off trying to create the cookie with PHP instead of JavaScript =)
    – Celeritas
    Apr 3, 2013 at 17:49
  • 6
    @Celeritas The reason is that if the browser has access to the cookies, any code running on the page has access to them. For authentication cookies particularly, This Is A Bad Thing, because if you have any cross-site-scripting (XSS) vulnerabilities on your site, an attacker could inject code that would steal a victim's authentication cookie, which the attacker would then use to impersonate the user. So, authentication cookies should be marked with the HttpOnly flag and so not accessible to JavaScript on the page.
    – Xander
    Apr 3, 2013 at 17:54
  • I get it now. If I create the session cookie with JavaScript and set the httponly flag, would that be better or still insecure compared to sending the cookie directly from the server?
    – Celeritas
    Apr 3, 2013 at 18:53
  • If there's ever a point it can be manipulated on client, it's going to be less secure than creating it on the server and sending it with the HttpOnly flag. However, if you immediately set the flag, then you've limited the attack surface to the page that creates the cookie. Personally, I don't care for it, but I can't immediately think of any issues that couldn't be overcome.
    – Xander
    Apr 3, 2013 at 21:25
  • 3
    An attacker with XSS can already impersonate the user completely inside the compromised browser window. httponly doesn't really prevent exploitation, it just makes it more annoying for the attacker as they have to do it in-browser instead of stealing the token and doing it locally. There are tools to make that easier though (see eg BeEF); if you have XSS you have effectively already completely lost. httponly is worth including if you can drop it in for cheap, but I wouldn't lose any sleep over a client-side app design that couldn't use it.
    – bobince
    Apr 4, 2013 at 17:47

I'm not a web developer so this could be wrong but I would expect that you could just use the Set-Cookie: header in the HTTP response to the AJAX query to set the session cookie.

You should not need to pass the session ID inside the AJAX response and then use Javascript to set that cookie. The standard PHP session_*() functions should handle setting the expiry time correctly for you.

On a security note, HTTPOnly, Secure and SSL. You should be doing all of these.

You should also be expiring sessions on the server both when the user logs out and after a certain period of inactivity from the user. The period you choose is a tradeoff between security and usability. The default in PHP is 1440 minutes (24 hours).

  • So it is because of programmers like you that people have to keep logging into sites and get automatically logged out, even when it's their own computer and they are the only person using it. How about giving the user the option
    – barlop
    Apr 26, 2019 at 22:28
  • You have to delete old session storage files from your server at some point or you will run out of disk space. Allowing the user to choose this time period adds complexity to the process which is why no one ever does it. You can implement a "remember me" function on top of session cookies which allows you to stay logged in forever but that's not what this question is about. You still get a new session cookie each time you visit a site with a "remember me" function.
    – Ladadadada
    May 1, 2019 at 11:08
  • 2
    @barlop nope its because of hackers, that try and guess your session id at 1000 per minute over 24 hours. and they take over your banking or payment session and take your money. yes programmers could double their length of cookie to make it hard to guess at all, and extend the cookie till 7 days.
    – hamish
    Jul 26, 2020 at 11:44

You must log in to answer this question.

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