Consider the standard CSRF protection of a Ruby on Rails application: a CSRF token is embedded in the HTML page, while at the same time stored encrypted as part of the session cookie. When making a request, the embedded token is sent along the cookie, and the server can then check whether they match.

Suppose now to open the same application in two separate browser tabs. They will have different CSRF tokens and as such different session cookies. However, when I make post requests there are no CSRF issues.

This raises the question: what is the scope of a browser cookie? If the scope were global (i.e. valid across different browser tabs), then as soon as I opened the second tab the first session cookie would have been overwritten (as they come from the same origin and have the same key). But I can make POST requests from the first tab, and they do not fail, implying that each tab has its own set of cookies.

On the other hand, if I log in in one tab and open a second one, I obviously have an application session in the second tab too, implying that cookies are shared across browser tabs.

So then, what is the true "scope" of a browser cookie?

1 Answer 1


... two separate browser tabs. They will have different CSRF tokens and as such different session cookies.

They don't.
The same cookie is used whenever you access the same site within the same browser, i.e. the scope of the cookie is not the current tab but the current browser.

That's why it is usually also impossible to login into the same site with the same browser at the same time. There are browser extensions to limit the scope of the cookie to the current tab in order to make multi-login possible but by default the scope is the current browser.

To be more precise: if you switch to a different browser you have a different context for cookies. If you switch to a different browser profile you get also a different context. Same when switching to private mode. But if you switch only to a different tab or window then you have the same context.

Note that a cookie might be additionally restricted by the path on the site using a path argument and might also include subdomains using the domain argument. See the section "Scope of cookies" at MDN:HTTP cookies for more details.

  • Unless i am overlooking something, they really do have different CSRF tokens, it is visible in the markup as a meta tag (for Rails applications that is). Or am i missing something trivial?
    – daniel f.
    Commented Jul 12, 2018 at 13:25
  • @danielf.: They will have the same session cookie. However, I think that Steffen Ullrich's answer partially answer your post, perhaps an addendum regarding the use of CSRF tokens in cookies could be added to explain the difference and why the scenario you describe happens.
    – Yuriko
    Commented Jul 12, 2018 at 13:36
  • @Yuriko: i guess then the question is more about how Ruby on Rails handles CSRF token. Thank you both for your input.
    – daniel f.
    Commented Jul 12, 2018 at 14:00
  • @danielf.: trying some ruby on rails using application like airbnb.com I get the same _csrf_token in all tabs on the same browser. Commented Jul 12, 2018 at 14:01
  • 1
    @PavelVoronin: If you have a cross site request (SPA1-domain to D) and another cross site request (SPA2-domain to D) then the cookie send to D within origin SPA1 will also be sent within origin SPA2. This is unless the browser employs additional separation between the origins as in Cookies Having Independent Partitioned State Commented Dec 4, 2023 at 14:53

You must log in to answer this question.

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