4 min readJust now
–
Press enter or click to view image in full size
In 2025, I came across this website(AI friend chatbot type).
And because Streaming response from an LLM to the frontend is something I have never worked with, I got curious to understand how their Backend works.
I just have this habit of opening the DevTools(learnt from the legend Hussein Nasser) on websites that I find interesting and observe the HTTP requests, what auth mechanism(JWT, cookies etc) is used, their API design etc etc.
It was a React frontend & Fast API backend, using Supabase for user sign-in/up + auth. And SSE(Server Side events) for chat messages with AI.
Supabase Tables publicly accessible:
…
4 min readJust now
–
Press enter or click to view image in full size
In 2025, I came across this website(AI friend chatbot type).
And because Streaming response from an LLM to the frontend is something I have never worked with, I got curious to understand how their Backend works.
I just have this habit of opening the DevTools(learnt from the legend Hussein Nasser) on websites that I find interesting and observe the HTTP requests, what auth mechanism(JWT, cookies etc) is used, their API design etc etc.
It was a React frontend & Fast API backend, using Supabase for user sign-in/up + auth. And SSE(Server Side events) for chat messages with AI.
Supabase Tables publicly accessible:
At the same time, there was this trend on X where people were bashing vibe coded apps leaking privileged supabase JWT & sometimes tables with no RLS i.e. anyone can query the tables.
So I gave it a try, just hoping to find something. I took their Supabase JWT, endpoint and made a request at (`/rest/v1`) via Postman. Their table schema was public(it’s common). Then I took a step further and wrote a small bash script to enumerate each table and see if they are accessible.
for table in $(cat tables.txt); do curl -H '<bearer-token>' "<supabase-endpoint>/rest/v1/$table?limit=1"done
Out of a few dozen tables, ~10 tables were publicly accessible i.e. I can access those tables. The most interesting tables were users messages and attachment . Their primary key was INT in all these tables, so it’s even more easy to guess the total rows etc. They were in millions 😰.
This means an attacker can basically see all the users, their messages & even the photos they have uploaded to the platform. Remember, that’s why it’s often advised to not share anything personal on random websites.
At this point I knew, this website has super serious security issues. I did some research on their social platform and sent an email to the founders reporting the Vulnerability. After 2–3 follow ups, I got a response that they are looking into it.
They made the tables private later, all good.
Backend auth gaps
I work with JWTs as part of my day to day work so I wanted to dig more in their APIs(which used this Supabase issued JWT when logging in via Google). In the backend/Supabase, users are identified by a UUID.
What I found was that the Backend had several serious security issues:
- They had a legacy Backend endpoint that had the OpenAPI spec publicly accessible. I found some private APIs(publicly accessible) in it that were not supposed to be public(e.g. bypass paywall for a user by making them temporarily Admin etc). I assume they were for internal testing only.
- IDOR vulnerability. Using a valid token, you can access any user’s info. It means if I log in and get my token. Using it I can access any other user’s info(their chats, profile, uploaded pics etc etc). But now how do we get the UUID of other users? Well, the platform has a feature where anyone can create an AI character(there are thousands of such characters already) and publish it publicly. So for each character, the API response also has it’s owner UUID ☠️.
- With edit message API, you could edit any message just using it’s ID(remember the primary key is INT) & a valid token. Doesn’t matter if the message actually belongs to the user owning the token.
- User uploaded pics were stored in Object Storage with current timestamp in nanoseconds & some random chars (so you can’t guess them) but if you had a link to it(remember the attachment table was public), you can access them without any auth 💀.
So all in all, any operation(send message, upload pics, see pics, conversation history etc) that you could do in your own account. You can also do it in any user’s account as long as you have their user id.
I reported this back to them and asked if there was any bounty for it.
Their response was:
We can give a bounty of $500. We are capping it at 500$ because we are already aware(** 💀**) of the bugs and working to fix it.
If you follow Bug Bounty Hunters, these bugs were very serious and were a tleast worth minimum few thousand $s. But it is what it is.
After the fixes I reported two more times that sums to a total bug bounty of 1000$.
All the issues were fixed a few months ago, hence I am writing this report now. I am not disclosing the company for obvious reasons.
My thoughts:
As a Backend developer, I think these security vulnerabilities are comparatively very easy to find, like I don’t know how come they even reached Production. I would say I just got lucky that I found them.
Fellas don’t randomly trust these new websites and for god sake, DO NOT upload anything personal on them, use temp emails or alt emails to signup. You never know what’s happening behind.
Until next time …