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
- I created an AI chat using Account A
- I opened the chat and submitted feedback while intercepting the request
- I copied the chat UUID from the feedback request
- I logged in using Account B
- I sent the same request using the copied UUID
- 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.