This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Talk:Testing for cookies attributes (OTG-SESS-002)

Jump to: navigation, search

Reviewer Note Rick.mitchell 10:33, 22 July 2008 (EDT)

Re: Section Title

"Testing for cookies attributes"

Something is wrong with this title. One of the following should be used:
Testing for cookies' attributes
(Multiple attributes belonging to multiple cookies)
Testing for cookie attributes
(Multiple attributes per cookie)
Testing for cookie's attributes
(Multiple attributes belonging to a cookie) Rick.mitchell 10:05, 22 July 2008 (EDT)

Domain attribute

There's an error in the Domain attribute explanation: "For example, if a cookie is set by an application at with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for and its subdomains (such as"

That's not correct. If the cookie set by an application at has no domain attribute set, then the cookie will be -only- submitted to and NOT to subdomains such as Also, if you set the attribute to "" the cookie WILL be submitted to subdomains.

In conclusion, it's more restrictive/secure if you leave the domain attribute unset.

Guillermo Caminer

Path attribute

The page seems to contain an error in the section about the cookie path attribute. I've highlighted the error in the quote below:

Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set too loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example, if the application resides at /myapp/, then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used, the browser will send the cookie to any path that matches "myapp" such as "myapp-exploited".

The current text says the trailing slash in the cookie path is important because, when omitted, a cookie for would also be sent to However, the relevant RFC 6265 contains the following path matching rules for browsers:

A request-path path-matches a given cookie-path if at least one of the following conditions holds:

o The cookie-path and the request-path are identical.

o The cookie-path is a prefix of the request-path, and the last character of the cookie-path is %x2F ("/").

o The cookie-path is a prefix of the request-path, and the first character of the request-path that is not included in the cookie- path is a %x2F ("/") character.

This would mean a cookie for /foo would never be sent to /foo-bar because

  • /foo is not identical to /foo-bar
  • /foo is a prefix of /foo-bar, but /foo does not end with a /
  • /foo is a prefix of /foo-bar, but -bar (the part of the request-path that is not included in the cookie-path) does not start with a /

If a browser adheres to the rules from the RFC the advice on the page is unnecessarily cautious. ";path=/foo" will have the same effect as ";path=/foo/".

PS I've tested this behaviour in Firefox 44.0.2 and Chrome 48.0.2564.109 m and those browsers both adhere to the RFC rules.