feat: add isServer property to server-side storage adapters

[hf]

This property will be picked up by auth-js (formerly known as gotrue-js) to warn or adjust behavior given that the storage medium (in this case cookies) cannot be trusted.

[kangmingtay]

i'm not too clear as to why we can trust the cookies if isServer=false - can you elaborate more on this?

[hf]

i'm not too clear as to why we can trust the cookies if isServer=false - can you elaborate more on this?

We can't trust the cookies when isServer=true (sorry for the reverse logic but it's simpler) because, suppose you're an attacker:

1. You find a vulnerable website that uses SSR, and uses getSession().user to render the user's bank account info.
2. You craft a cookie header that includes the user you want, with an expires_at and expires_in that are in the future, so the client library doesn't try to refresh the session.
3. Boom. Next.js SSR will render any user's banking information because getSession().user ultimately does not verify the authenticity of the data inside the cookie. Only the JWT can be authenticated, but that is only done by getUser().

It's very easy to miss; it's also easy to miss by just thinking that getSession() acts as an authentication barrier.

In the reverse case where isServer=false the cookies can be trusted, in the sense that they're somehow authenticated. Let's say that the developer builds a custom storage adapter that authenticates the data inside the cookie -- like a JWT containing the JWT.

[hf]

isServer is just a hint to the gotrue-js/auth-js library to know what sort of storage is being used so it knows to warn / adjust behavior based on prioritizing security over performance.

[kangmingtay]

@hf but the same thing holds true if getSession is used on the client right? Or is it much harder because the attacker will need access to the user's browser?

[hf]

because the attacker will need access to the user's browser?

Yes, or to the underlying server -- which are both scenarios out of any security model on the web.