API Key Exposure & Insecure Supabase Access: a Bug Hunt

Like other developers I regularly lurk dev space subreddits, and came across a post by a business dev at a startup who had developed a lead generation micro-SaaS. User’s need to make an account and can use the site to find sales leads, do targeted outreach, etc using various paid subscription options. Observing the Signup Flow: The developer asked other redditors to test the site and provide feedback, so as a first validation step I tried to sign up with an invalid email to test it and took a closer look at the sign up POST request. Given it’s an invalid email, I did not actually sign up or login, I was still on the sign up page with an error saying the email was invalid. From the POST request info I saw that the site used a Supabase, and I could also see the API key and Authorization in the headers. Generally, if this is an anon key and the backend has RLS (Row Level Security) enabled this is not a problem. The frontend uses this token to make calls to Supabase, and RLS + policies determine what the user is allowed to see/do. Supabase's client libraries often expose an anon API key for public access, but it must be protected with Row Level Security (RLS). Investigating the API Key & Triaging the Bug: To test that theory, I made a GET request to an endpoint I guessed https://.supabase.co/rest/v1/leads - the SaaS provides marketing leads, so I figured /v1/leads is as good as a guess as any) and added the exposed API keys as part of the request header - I got back hundreds of leads data. This confirmed that the table was publicly accessible, likely without any RLS or access restrictions, thanks to the exposed API key. I tested further by exploring if other tables were exposed. I had read access to pretty much everything as long as I could guess a valid endpoint - leads, users, marketing data, etc. For obvious reasons I did not test any write access. Disclosure: I reached out to the site owner, shared the issue privately and explained how the API key was exposed. They acknowledged the issue and said they would investigate and patch the exposure. Client-side keys must be used with backend-enforced access controls like RLS. Whether you're a frontend dev, tester, or backend engineer, this was a great reminder of how small oversights can lead to critical data leaks. So if you’re working with Supabase, make sure your tables are protected with RLS, and don't assume API key obfuscation is a substitute for access control.

Apr 22, 2025 - 07:15

API Key Exposure & Insecure Supabase Access: a Bug Hunt

Like other developers I regularly lurk dev space subreddits, and came across a post by a business dev at a startup who had developed a lead generation micro-SaaS.

User’s need to make an account and can use the site to find sales leads, do targeted outreach, etc using various paid subscription options.

Observing the Signup Flow:
The developer asked other redditors to test the site and provide feedback, so as a first validation step I tried to sign up with an invalid email to test it and took a closer look at the sign up POST request.
Given it’s an invalid email, I did not actually sign up or login, I was still on the sign up page with an error saying the email was invalid.
From the POST request info I saw that the site used a Supabase, and I could also see the API key and Authorization in the headers.

Generally, if this is an anon key and the backend has RLS (Row Level Security) enabled this is not a problem. The frontend uses this token to make calls to Supabase, and RLS + policies determine what the user is allowed to see/do. Supabase's client libraries often expose an anon API key for public access, but it must be protected with Row Level Security (RLS).

Investigating the API Key & Triaging the Bug:
To test that theory, I made a GET request to an endpoint I guessed https://.supabase.co/rest/v1/leads - the SaaS provides marketing leads, so I figured /v1/leads is as good as a guess as any) and added the exposed API keys as part of the request header - I got back hundreds of leads data.

This confirmed that the table was publicly accessible, likely without any RLS or access restrictions, thanks to the exposed API key.
I tested further by exploring if other tables were exposed. I had read access to pretty much everything as long as I could guess a valid endpoint - leads, users, marketing data, etc. For obvious reasons I did not test any write access.

Disclosure:
I reached out to the site owner, shared the issue privately and explained how the API key was exposed. They acknowledged the issue and said they would investigate and patch the exposure.

Client-side keys must be used with backend-enforced access controls like RLS. Whether you're a frontend dev, tester, or backend engineer, this was a great reminder of how small oversights can lead to critical data leaks.

So if you’re working with Supabase, make sure your tables are protected with RLS, and don't assume API key obfuscation is a substitute for access control.