[mooreds]

But when you can use them, cookies are demonstrably better. XSS is the main argument against localstorage. Even this article[0], which pillories cookies, starts off with:

   ...if your website is vulnerable to XSS attacks, where a third party can run arbitrary scripts, your users’ tokens can be easily stolen [when stored in localstorage].

The reasons to avoid cookies:

* APIs might require an authorization header in the browser fetch call.

* APIs might live on a different domain, rendering cookies useless.

CSRF is a danger, that's true. can be worked around. My understanding is that XSS has a wider scope and that many modern frameworks come with CSRF protection built in[1]. Whereas XSS is a risk any time you (or anyone in the future) includes any JS code on your website.

0: https://pilcrowonpaper.com/blog/local-storage-cookies/

1: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

[arkh]

> * APIs might live on a different domain, rendering cookies useless.

That's when you implement a BFF which manages your tokens and shares a session cookie with your frontend while proxying all requests to your APIs. And as said, you "just" have to setup a way for your BFF to share CSRF tokens with your frontend.

[mooreds]

Yup, big fan of the BFF. Philippe de Ryck did a presentation on the fundamental insecurity of token storage on the client that he allowed us to share: https://www.youtube.com/watch?v=2nVYLruX76M

If you can't use cookies (which as mentioned above, have limits) and you can't use a solution like DPoP (which binds tokens to clients but is not widely deployed), then use the BFF. This obviously has other non-security related impacts and is still vulnerable to session riding, but the tokens can't be stolen.

[arkh]

> Philippe de Ryck

Almost certain it is one of those presentations which got me on the BFF bandwagon. Really awesome speaker.