> I think OWASP recommend cookies rather than localStorage but it would be good to see the different risks each protocol or storage location comes with in an authorative guide with the pros and cons of each and which shouldn’t be used and why. I.e. there seems to be lots of footguns on top of the complexity of having to choose the appropriate OAuth flow.
The mental model I have for web storage these days is of three buckets per site:
1. Server data like secure-http-only cookies and negotiated information like HSTS
2. Javascript-accessible persistent storage
3. Javascript-accessible session storage
Databases, Javascript storage API and cookies get partitioned into these buckets per site (e.g. eTLD+1). Some browsers may also extend these to support unique state for embedded sites - an advertising script can set a tracking cookie, but it will have a different cookie for each domain that the script is placed on. Likewise to prevent tracking, they may put the actual page caching into per-site storage (possibly a 4th bucket)
The browser may have its own expiration policies for these buckets in addition to any policy you set - Safari for instance will expire javascript-accessible persistent storage after a week of active use without interacting with a site, even if the cookies have an expires header farther in the future.
The browser exposes this data set as cookies, caches, local/session storage api, IndexedDB, and negotiated behavior like HSTS.
A guide to understanding all of these would be useful. But generally, the combined "most restrictive" browser behavior is that these are just different views on top of the same storage buckets.
The significant odd-one-out is a HttpOnly and Secure cookie. This may have a different expiration policy, and may be strongly desirable for say authentication systems which are trying to remember a user or device for an extended period of time, possibly for a risk tracking basis. These cookies also tend to be the ones which are synchronized across browser instances - so they are valuable for single sign-on and behavioral synchronization with installed PWAs as well as for native app use cases using the browser for authentication.
OWASP likely prefers cookies because they have policy options to be secure and http only - I as an attacker cannot downgrade to a fraudulent HTTP site to extract secure cookies, nor can I inject scripts that will exfiltrate HttpOnly session cookies.