← Back to Writeups

IDOR via UUID – User Chat Leakage and Deletion

Severity: Medium

Category: IDOR / Access Control

Platform: Public Program

What I Found

While testing an AI chat feature, I noticed that user feedback was sent through an API endpoint using a UUID to identify the chat session.

This identifier was fully controlled by the client, and no proper ownership check was enforced on the server side.

How the Issue Works

When submitting feedback for an AI chat, the application sends a request similar to the following:

PUT /api/feedback
{
  "rating": 1,
  "comment": "",
  "id": "chat-uuid-here"
}
      

By replacing the chat UUID with the identifier of another user’s chat, the server still accepted the request and returned a successful response.

As a result, I was able to view the chat content, and the original chat was removed from the victim’s account.

How I Reproduced It

  1. I created an AI chat using Account A
  2. I opened the chat and submitted feedback while intercepting the request
  3. I copied the chat UUID from the feedback request
  4. I logged in using Account B
  5. I sent the same request using the copied UUID
  6. The chat appeared in Account B and was deleted from Account A

Why This Matters

This vulnerability allows attackers to access and delete other users’ AI chat history by abusing an insecure direct object reference.

Even though the chats are generated by an AI, users may share sensitive or personal information. This issue affects both confidentiality and integrity and can lead to permanent data loss.

Final Thoughts

API endpoints that rely on object identifiers must always verify ownership on the server side. Client-supplied UUIDs should never be trusted without proper access control checks.