Headless API documentation potentially incorrect? (otherwise, might lead to a CSRF vulnerabilty?)

[luisvalerio]

Hello!

I'm looking at the headless API documentation for /_allauth/app/v1/auth/session, and it says the response schema contains a session_token field under meta when client is app. Which, if it was true, it could be a way for an attacker to obtain/steal the Session key by simply forging a request (CSRF) to that endpoint and getting the session key back(?). However, it seems like the session_token is actually not returned by this endpoint (by looking at this line) as well as testing the endpoint locally.

So my question is, is the documentation incorrect and it should probably be updated to remove this field from the schema? Or, am I missing something AND there IS a way for this endpoint to return the session_token (without changing the default Token Strategy/adapters)...I'm asking since this would impact the security considerations of an app I'm building (so I want to know that default allauth endpoints won't give my session keys/tokens via CSRF attacks like that one).

CCing @pennersr as the author for an expert opinion (let me know if I shouldn't be tagging you directly and/or if there's someone else I should be tagging for this type of question and/or if I shouldn't tag anyone at all on future questions and simply let the community answer it organically 😄 )

Thanks!!

[pennersr]

The app endpoints don't rely on cookies. As a result, a CSRF attack wouldn't work.

Indeed, the documentation shows an example payload there that is not correct. The tokens are only exposed once -- when they are actually issued -- and not repeatedly for each and every other request.

[luisvalerio]

That makes sense, thanks for the clarification!