Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

The answer to this question about how cookies are potentially vulnerable between sub-domains sparked my curiosity.

As far as I know, if a cookie is set on a sub-path of the same domain (www.example.com/dogs), then it is not accessible to any other path, unless it's a sub-folder of the path. i.e. neither www.example.com/cats nor www.example.com/ should have access to those cookies, but www.example.com/dogs/labrador would.

Reading further, I see it's possible to get the cookies from different paths:

It is important to note that the path restriction does not protect against unauthorized reading of the cookie from a different path. It can easily be bypassed with simple DOM (for example by creating a hidden iframe element with the path of the cookie, then accessing this iframe's contentDocument.cookie property). The only way to protect cookie access is by using a different domain or subdomain, due to the same origin policy.

If that's the case, then what security (or even functionality) does the cookie-path provide? And if it can be read using an iframe, why isn't it accessible directly in javascript? Does this "restriction" actually give a false sense of security?

share|improve this question
add comment

1 Answer

up vote 8 down vote accepted

The cookie path doesn't provide any security (in most real-world situations).

It is important to understand that the cookie spec is ancient technology. It dates back from the earliest days of the web. The security model of the web has evolved since then, and become more carefully thought-out. The security model for cookies hasn't evolved correspondingly.

As another example of impedance mismatches between the web's security model and cookies, the same-origin policy treats www.example.com:80 as a different origin from www.example.com:81, but they are treated as identical for purposes of cookies. You can find more discussion of security oddities with cookies from Michal Zalewski.

Cookies can be read by Javascript. While the browser may take the path into account when Javascript tries to read cookies, this is not a security feature: the path is not a security boundary, so malicious Javascript on one page can still read cookies for other paths (e.g., by opening an invisible iframe with the proper path, injecting malicious Javascript into it, and then grabbing the cookie). The only effective security boundary is at the granularity of an origin. As a result, the bottom line from a security perspective is: malicious Javascript on www.example.com/dogs can read a cookie whose path is www.example.com/cats.

In practice, developers typically avoid these corner cases that are left over from earlier days, or at least avoid relying upon them to provide extra security. For instance, web developers should not rely upon the cookie-path to provide security (at best it reduces the number of cookies sent back, which could perhaps be used to reduce bandwidth in some situations). As another example, sites these days usually avoid serving content from non-standard port numbers, since that situation is another corner case that exposes unexpected semantics.

At this point, the cookie path is mostly a vestigial remnant of earlier days. It doesn't serve much purpose any longer, as far as I can tell, and if the cookie-path had never been introduced, today you'd probably never notice. But browsers still need to support it, for backwards-compatibility reasons. And so it goes, on the web. It is best to think of the web not as a carefully designed artifact but as something that evolved over time -- and as a result, has accumulated now-useless gunk, like our appendix.

share|improve this answer
+1. One valid benefit of cookie paths, is if you need to have (for some reason) different cookies with identical names in the different paths. For example if you have two instances of the same application installed in parallel... The cookie path is simply a selector, to ensure the correct cookie gets sent to the correct application - but as you say it is not a security boundary. –  AviD Mar 6 '12 at 6:56
Thanks D.W and @AviD. That's more or less what I thought. (+1 for the difference in SOP, didn't realise that either!!). However I am not sure "The cookie-path is ignored when Javascript tries to read a cookie" is entirely correct. You'd have to use tricks like iframes to do this. This is the part I wonder most about - why restrict javascript when it gives you no security anyway? –  Yoav Aner Mar 6 '12 at 8:10
@YoavAner again, I think this has more to do with clarity, than any form of security enforcement. If the cookie is not in scope, why should you see it? Not that you can't, or shouldnt be able to, but by default there is no reason for it. –  AviD Mar 6 '12 at 8:29
@AviD - makes sense, just that it might give a false sense of security. D.W. I've accepted your answer, but I think the sentence I mentioned above might still need correction or clarification. –  Yoav Aner Mar 6 '12 at 8:59
@YoavAner, you are right. Sorry, on re-reading, I realized I mis-read your question. I've updated my answer accordingly. As far as why browsers restrict Javascript when it gives no security -- I don't know. Perhaps it is cleaner to stay consistent with how cookies are treated elsewhere in the browser. Perhaps it is, as AviD explains, to enable people to have two instances of the same application (or two different application with overlapping cookie names) installed at the same time -- not to provide a security boundary between them, but just to let them function. –  D.W. Mar 6 '12 at 20:22
show 1 more comment

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.