V3.4.4 - Questionable advice to limit path attribute

[securitybits]

The statement "Verify that cookie-based session tokens limit the 'path' attribute to the most precise path possible." is questionable at best in my view. What is the purpose?

The path limitation is only theoretical, in practice it doesn't do anything for security since the same-origin policy doesn't take the path into account. Besides, this advice goes against the requirements for using the __Host- prefix, which is something we should encourage people to use.

[elarlang]

See #426. In practice - it does help against information leakage to other paths, IF application is located in some path (folder).

[securitybits]

@elarlang No I don't think it provides any real protection, especially not for a session cookie. A site under a different path is still on the same origin and has full access to issue authenticated requests that automatically include the session cookie anyway - e.g., it's the same as an attacker had an XSS on the target site. Not worth the effort, and counterproductive as it would be incompatible with the __Host- cookie prefix (which DOES provide tangible security benefits).

[elarlang]

e.g., it's the same as an attacker had an XSS on the target site.

That's true and just one part of it. Consider also problem, when different sites are in different folder and they use by default the same name for session cookie, like JSESSIONID or PHPSESSID. Then different sites override other site cookies. Not a huge issue by likelihood but if you can do something correctly, then it makes sense to do it.

Not worth the effort, and counterproductive as it would be incompatible with the __Host- cookie prefix (which DOES provide tangible security benefits).

Is __Host- prefix ready to be recommended? I guess not. Still not supported by many browsers.
If it is ready, then requirement should be in style "use __Host- prefix OR set path correctly"