Browser
Chrome
Area
Auth (login / Google sign-in)
Steps to reproduce
1)Run the app locally and log in via Dev Login as user A.
2)Open any ride created by a different user B (e.g. GET /api/v1/rides/:id). Note poster.id in the response — that is B's user ID.
3)Open DevTools → Application → Cookies → edit splitt_session, replacing your value with B's user ID.
4)Call GET /api/v1/auth/me (or refresh the app).
Expected behavior
Editing the session cookie to another user's ID should not authenticate you as that user. A tampered or forged session should be rejected (e.g. 401 Not signed in), because a real session token is signed/verified server-side.
What actually happened
GET /api/v1/auth/me returns user B's account (their email, name, profile). You are now fully acting as B — you can post, join, cancel, and rate as them. Any user whose ID appears in an API response can be impersonated.
Suggested fix:
-Stop using the raw user ID as the cookie. Use a verifiable session instead — either:
-a signed token (e.g. JWT signed with a server secret), so an edited cookie fails signature verification, or
a random opaque session ID stored server-side that maps to the user (the cookie reveals nothing and can't be forged).
Logs / Screenshots
No response
Browser
Chrome
Area
Auth (login / Google sign-in)
Steps to reproduce
1)Run the app locally and log in via Dev Login as user A.
2)Open any ride created by a different user B (e.g. GET /api/v1/rides/:id). Note poster.id in the response — that is B's user ID.
3)Open DevTools → Application → Cookies → edit splitt_session, replacing your value with B's user ID.
4)Call GET /api/v1/auth/me (or refresh the app).
Expected behavior
Editing the session cookie to another user's ID should not authenticate you as that user. A tampered or forged session should be rejected (e.g. 401 Not signed in), because a real session token is signed/verified server-side.
What actually happened
GET /api/v1/auth/me returns user B's account (their email, name, profile). You are now fully acting as B — you can post, join, cancel, and rate as them. Any user whose ID appears in an API response can be impersonated.
Suggested fix:
-Stop using the raw user ID as the cookie. Use a verifiable session instead — either:
-a signed token (e.g. JWT signed with a server secret), so an edited cookie fails signature verification, or
a random opaque session ID stored server-side that maps to the user (the cookie reveals nothing and can't be forged).
Logs / Screenshots
No response