I have been looking through the OWASP session management cheat sheet and I don't understand the reasoning behind the suggestion to "Disable Web Browser Cross-Tab Sessions". How does using the same session id for multiple browser tabs present a security vulnerability?

2 Answers 2


It's probably under the idea that if one browser tab gets compromised, them the other browser tab may not be compromised.

This might help reduce the impact of emailed malicious links. For example, click on the link in an email to try and execute a reflected XSS vuln and you get a new tab without a session, then the link has no effect. There might be other similar vulns that this might be designed to help with, as well.

However, this appears to be is a complex solution to provide defense in depth for only part of a security flaw where the real solution is a properly architected application that uses appropriate secure frameworks (like a secure web ui framework) to prevent the issue in the first place in a far less complicated way that doesn't break normal usability of web applications.


I would guess that in principle it's because it's to prevent possibility of a Bad Person hijacking your session.

If such a person were to be tapping your session then would have your cookie (or less trivially whatever magic value in the pages is identifying your session) and then all they'd have to do is spoof your IP-address.

Of course if your session were encrypted this shouldn't be possible, but presumably this rule doesn't presume it to be the case, or rely upon it.

It's not something HTTP itself can deal with, but the rule itself notes that:

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to re-authenticate

So you couldn't support users who don't wish to use JavaScript, or whose browser doesn't support it. Your session-tracking logic then, implemented in JavaScript lets say, retains session information local to the browser-tab session only. You need to ensure that this implementation also is portable across whatever browsers you wish to support.

I'd recommend using a well known implementation for this rather than rolling your own. I'd imagine most well known JavaScript frameworks support this.

There's more on what you might specifically need to do here: https://stackoverflow.com/questions/11008177/stop-people-having-my-website-loaded-on-multiple-tabs


There are another few scenarios that come to mind.

A ticket sales site might like to do something like this to prevent their customers "gaming" a queueing system by running multiple tabs. But this is a session management issue really, because the customer is effectively running multiple "queueing sessions" within their actual session.

It can also simplify site design if you don't need to worry about race conditions between different user activities thus forcing them to do "one thing at a time", though this is more of a UX than a security issue.

Finally, this rule could also frustrate the activities of scraping software, or bots (such as those that could be used on ticket sites again for instance). This would be an effective countermeasure against an attacker logging in through the browser to capture a session, and then continuing the session with the bot.

  • However, this does NOT prevent opening multiple browser tabs from inside the session. Eg, if I open 2 tabs for www.example.org, these will be in different sessions. But if I from a logged in session, right click and select "Open in a new tab" or "Open in a new window", both windows/tabs will belong to the same session. The only way to defend against this is to have a one-time session ID (like a CSRF token) embedded on all pages, that is only valid for one single request. Opening a new tab will then invalidate the token and log out the old tab, forcing session continuation on the new tab. Nov 25, 2015 at 22:36
  • I'm not sure what you mean. I didn't specify an implementation and the owasp documentation doesn't either, but recommends Javascript. The scheme you describe (a one-time session ID) is susceptible to attack in the scenario I described (Charlie hijacking Anne's non-ciphered conversation with Barry after some eavesdropping).
    – robert
    Nov 26, 2015 at 9:33
  • No, its not suspectible to attack, since when Charlie has hijacked the conversation and Anne or Barry do send something with the now invalidated session ID, the whole session will be killed, causing Charlie to be kicked out aswell. The only thing Charlie can do is to passively listen. Nov 29, 2015 at 2:28
  • So what about when Anne walks away from her session without logging out sebastien?
    – robert
    Nov 30, 2015 at 8:32
  • That is a viable risk, but the attacker is unable to see if Anne walks away from the session. The only thing the attacker can do, is hoping lack of communication is a sign of Anne walking away. Periodic session refreshes can mitiage this risk, because then the attacker cannot differentiate between anne being active, or just periodic session refreshes. Also, when a session refresh occurs with a invalidated session key, then the attackers session is killed aswell. Dec 1, 2015 at 3:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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