15

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?

2
  • A hidden iframe element can be stopped by the framed path sending X-Frame-Options: DENY header, which whoever controls the server should be able to do.
    – iBug
    Apr 18, 2021 at 13:30
  • @iBug An iframe is not the only way to get hold of a window reference; window.open is another. And X-Frame-Options has no effect, in this case.
    – jub0bs
    Jul 26, 2022 at 11:53

1 Answer 1

26

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.

8
  • 4
    +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, 2012 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, 2012 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, 2012 at 8:29
  • 2
    @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, 2012 at 20:22
  • 3
    I think it is worth mentioning that using the "http-only" flag on cookies on different paths actually do prevents script access to reading cookie values across sub-paths.
    – PålOliver
    Aug 31, 2016 at 7:16

You must log in to answer this question.

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