Here, several servers in the same DNS domain emit cookies under a variety of settings (scope, HTTPS, Secure) and another host emits a cookie with the same value.


Suppose a user has the following cookie set at secure.example.com:

 authCookie = SomeSessionToken (Scope example.com, Secure, HTTPOnly)

Then the user goes to a blog.example.com that is compromised (perhaps in another tab). It sets a non HTTPOnly cookie like this:

 authCookie = AlternateSessionToken (Scope example.com, Secure, not-HTTPOnly)

Would the next request to secure.example.com use the alternate credentials?

Is this scenario possible?
--Will the browser set two different cookies(with the same name) for two respective servers?

--Or the authCookie gets overwritten?


1 Answer 1


Summary. Yes, this is possible. It's not a browser bug. It is part of the as-designed functionality of cookies. There is no browser that is safe from this. Cookies are ancient technology and their security model is only loosely-integrated with the rest of the web. The details are messy and ugly.

The gory details

The site blog.example.com can set cookies with scope blog.example.com or with scope example.com. Cookies with the latter scope will be sent back to secure.example.com, if the user visits secure.example.com.

If the site secure.example.com sets a cookie with scope example.com, then the site blog.example.com can overwrite that cookie arbitrarily. Whenever browsers see a cookie with the same name and scope as one that's already in the cookie jar, they discard the old cookie value and overwrite it with the new cookie. Thus, blog.example.com can overwrite any cookie whose scope is example.com.

Worse still, one cookie can shadow a cookie with another scope. Suppose secure.example.com sets a cookie with scope secure.example.com and name SESSIONID. Next suppose blog.example.com sets a cookie with scope example.com and the same name. Finally, suppose the user visits the site secure.example.com. What happens? It is ugly: the browser sends both cookies, in some undefined order, and the server has no reliable way to tell which cookie value came from which site. So, the server can detect that it is in a confusing situation, but has no good way to unconfuse itself. Worse, some web application frameworks may conceal the confusion from application code, using one of the cookie values and silently ignoring the other. This can lead to something that behaves effectively like blog.example.com overwrote the cookie from secure.example.com, in a situation where no one would reasonably expect that it might be able to.

(As a side note, the secure flag does not prevent a cookie from being overwritten. In fact, a HTTP site can overwrite a cookie with a secure flag, as long as the domain names are related appropriately. The secure flag provides confidentiality protection but not integrity protection.)

Finally, there is one other way to delete cookies: a malicious site can set lots of cookies, overflowing the fixed limit on the number of cookies that the browser will store. The result is that the browser "forgets" older cookies from other sites. This allows blog.example.com to delete all of the cookies set by secure.example.com (regardless of their scope), and then set a new cookie with scope example.com that will be sent back to secure.example.com -- which has much the same effect as overwriting an existing cookie. This may be what you were thinking of when you mentioned "cookie jar overflow".


It's messy. Sad to say, this is just how cookies work on the Internet. If you want to avoid it, the simplest defense is to use a new second-level domain for untrusted sites. There's probably a better defense that doesn't restrict the naming of your sites, but I don't know what it is.

As a general note, for questions like these about how the web works, I highly recommend the browser security handbook. It is packed with nuggets. In this case, you might want to read its material on the same-origin policy for cookies.

  • 1
    +1. Great explanation. Are there similar concerns with cookie paths on a single domain? If a cookie is set on /subfolder path then it's not accessible from the root of the domain or another sub-folder, but can the same attacks methods be executed in this case?
    – Yoav Aner
    Mar 5, 2012 at 8:56
  • Thank you; I think this has implications for Active Directory... your advice on the linked question is appreciated Mar 5, 2012 at 9:57
  • 2
    @YoavAner, my understanding is that you should not count on the path to provide any extra security. For instance, Javascript from a site S can read all cookies for S, regardless of path.
    – D.W.
    Mar 5, 2012 at 18:15
  • 2
    You can prevent some attacks by digitally signing your cookie content with a different private key for each individual application. This would allow you to detect when a cookie had been tampered with, and thus reject the request on the server side. This can be done without any special browser support. It would not help you at all with a cookie being "deleted", and you could also potentially still be vulnerable to replay style attacks.
    – Nathan
    Jul 16, 2013 at 17:42
  • 1
    For more on this, see: github.com/blog/1466-yummy-cookies-across-domains
    – Ajedi32
    Dec 23, 2015 at 17:52

You must log in to answer this question.

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