Security risks to returning JWT token in the response body to a GET request?

Question

Are there any security risks to returning a user's JWT in the response body to a GET request? The JWT is only returned for authenticated users. Authentication is managed via a JWT stored as a HttpOnly, Secure, SameSite:Lax cookie.

Flow, in detail:

1. User makes GET request to my.com/api/session. The request includes the user's JWT cookie mentioned above.
2. Server validates the authentication cookie, and – for authenticated users – returns the JWT in the response body.

Is there a risk of a CSRF attack in browsers that don't support SameSite:Lax? In those cases, could a malicious site make the GET request to my.com/api/session and – if the user is logged into our site – have the JWT cookie automatically included in that request?

Answer 1

... malicious site make the GET request to my.com/api/session and – if the user is logged into our site – have the JWT cookie automatically included in that request?

Yes, this is possible. But due to the nature of Same Origin Policy the malicious site cannot directly cross-origin read the result of the request.

Depending on how the JWT is exactly delivered it might be possible though to observe effects of the JWT and thus get to the value. For example if the body of the response consists of name=value it might be possible for an attacker to do a cross-origin script include for the resource and then be able to access the value though name from Javascript.

Variations of this exist and issuing the JWT itself (even not read) might also have unwanted side effects at the server. So it is better to detect such cross-origin request at the server. This can be done with classic CSRF tokens, by observing headers like Referer, Origin or (in newer browsers) Sec-Fetch-Site, by requiring a special non-standard HTTP header (which results in a CORS preflight on cross-origin requests).