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

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

 authCookie = SomeSessionToken (Scope, Secure, HTTPOnly)

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

 authCookie = AlternateSessionToken (Scope, Secure, not-HTTPOnly)

Would the next request to 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?

share|improve this question
See also: How can we protect ourselves from cookie attacks ... the answer is that there isn't a solution. TLS-OBC is a potential RFC candidate that may fix this – LamonteCristo Mar 16 '12 at 16:20
"a non HTTPOnly cookie like this:" non HTTPOnly, or HTTPOnly? – curiousguy Jun 28 '12 at 0:03
up vote 31 down vote accepted

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 can set cookies with scope or with scope Cookies with the latter scope will be sent back to, if the user visits

If the site sets a cookie with scope, then the site 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, can overwrite any cookie whose scope is

Worse still, one cookie can shadow a cookie with another scope. Suppose sets a cookie with scope and name SESSIONID. Next suppose sets a cookie with scope and the same name. Finally, suppose the user visits the site 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 overwrote the cookie from, 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 to delete all of the cookies set by (regardless of their scope), and then set a new cookie with scope that will be sent back to -- 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.

share|improve this answer
+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 '12 at 8:56
Thank you; I think this has implications for Active Directory... your advice on the linked question is appreciated – LamonteCristo Mar 5 '12 at 9:57
@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 '12 at 18:15
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 '13 at 17:42
For more on this, see: – Ajedi32 Dec 23 '15 at 17:52

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.