Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have logged into my application and I received a session token. When I navigate to another tab, the application pertains the same session token.

Is it normal behavior that the session token does not change when you navigate to another page after logging in?

share|improve this question
I think the title of this question doesn't really relate to the question asked in the body. While the title is about application behavior (when to generate session tokens), in the body you ask about general browser behavior (tab handling and cookie jars). Please clarify! – buherator Jul 2 '13 at 14:23
@buherator - The OP's original question was more about whether a website can be secure, if it doesn't regenerate the session-id after a login. – martinstoeckli Jul 2 '13 at 19:23

Regenerating the session-id is one of many points, that makes your application more secure. It makes sense when the user increases his privileges (login), to avoid session-fixation attacks.

There are other possibilities to achieve the same goal, so you cannot tell from the unchanged session-id alone, that the application is unsecure. An other way to make session-fixation more difficult, is to use a separate authentication-cookie, for example.

share|improve this answer

The notion of session is supposed to follow the user, or, more precisely, the user's browser on a given machine. It is not supposed to be specific to a tab or windows, because tabs and windows (in the usual Web architecture) are a local concept which the user opens and closes at his discretion. By definition, the session also spans several successive pages.

In order to implement the notion of session, many sites push into the browser (as a hidden form field, a cookie, URL rewriting or some other technique) a session token which does not change from page to page (because it has no need to change). This is normal. One can imagine a session-management system where what is stored client-side morphs from page to page, but that would be more complex, with no clear advantage over a simple unchanging session token.

share|improve this answer

You need to regenerate the token every time a user successfully logs in. The session allows the server to map a user to a certain state (the session). What you do need to make sure is that:

  • the session token changes if a session token is generated before logging in
  • the session token is a completely random number (really random, not some algorithm you developped yourself which is derived from a username, password or time interval)
share|improve this answer

The whole point of the session ID is that it stays constant throughout the session and creates a one-one connection between the logged-in client browser and the server. There's no need to keep changing it every time the user opens a new window.

Change it during login/logout, though.

share|improve this answer
Yes, there is. Session fixation attacks are possible if not. – kinunt Jul 2 '13 at 12:07
@kinunt Example? Protecting against session fixation is done differently, you don't feed a new session cookie to the browser every pageload. – Manishearth Jul 2 '13 at 12:56
I did not mean in every pageload, that will almost invalidate the purpouse of the session cookie, I mean to change the session cookie during authentication (before being authenticated and after being authenticated). Examples of session fixation attacks:… – kinunt Jul 2 '13 at 12:59
@kinunt Solution: Don't accept the session ID in the query string (let the server create them). Make sure your cookie domains are set correctly. Don't loosen the CORS. IMO changing the session ID for every pageload isn't how you solve this. – Manishearth Jul 2 '13 at 13:03
@kinunt Oh, I see. I'll edit that in, hadn't occurred to me. Thanks :) – Manishearth Jul 2 '13 at 13:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.