Conversation IDOR

Problem

Conversation endpoints appear to trust request-supplied identifiers instead of enforcing ownership from authenticated identity.

Observed behavior:

• GET /conversations/{id} and DELETE /conversations/{id} do not check ownership.
• Conversation list, share, and report flows use caller-supplied user_id, so ownership checks are spoofable.

Risk

A caller can potentially read, delete, share, or report conversations they do not own by changing path IDs or supplied user_id values.

Expected behavior

Conversation authorization should be based on the verified authenticated user, not a caller-supplied user identifier.

Acceptance criteria

• Backend derives user identity from a verified auth token.
• GET, DELETE, list, share, and report conversation endpoints enforce ownership or explicit share permissions.
• Caller-supplied user_id is not accepted as proof of identity.
• Regression tests cover wrong-user access attempts for each affected endpoint.

Start by tracing the conversation GET, DELETE, list, share, and report endpoints and the verified-auth-token handling. Add regression tests for wrong-user access to each affected endpoint, including attempts using caller-supplied user_id values. Done means ownership or explicit share permissions are enforced consistently across all listed flows.