RFC6265 said that
If the server omits the Path attribute, the user agent will use the “directory” of the request-uri’s path component as the default value.
Though it talks about the Set-Cookie thing, it also applies to the document.cookie API. To verify this, one can open new tab on Chrome and type “https://github.com/pulls/review-requested”. Once the webpage finished loading, open the dev console, type the following code and enter:
document.cookie = "mycookie=114514"
The application tab in dev console shows that the cookie is created with the path “/pulls”, which is exactly what is mentioned in RFC6265. But it seems to be a little complicated if SPA is involved (though github is indeed written in react). Let’s follow the steps:
- Open a new tab to github.com. You’d better delete the cookie above.
- In order to change url to “https://github.com/pulls/review-requested” without reloading, click the pull request button on the top-right, and then click the button with text “Review requests”.
- Type
document.cookie = "mycookie=114514"in dev console and check the value in the application tab.
At this time, the cookie is created with the root path “/”, even if Chrome’s address bar is filled with https://github.com/pulls/review-requested .
That seems to differ from RFC6265. I have tried it on Firefox, which behaves the same as Chrome. I can’t figure out the following questions:
- How is the missing path attribute of a cookie is computed or handled via the
document.cookieAPI? - Are there any articles that document the way path of cookie is computed?
8
Strictly speaking, it is working within the limits of the specifications. As you noted, the browser will set the path to the request-uri’s path component. As the browser did not make the SPA request, the request uri’s path component is still ‘/’.
This has security benefits, for instance, this logic would make it so a XSS attack could not use the History API to change the path and bypass cookie path restrictions. This should be an important precaution for larger websites.