On 14 October 2026, UpGuard published research reporting 16,326 Supabase databases with publicly readable tables. The headline number is real and documented. But some of what has circulated about the study mixes what was measured with what the authors inferred. If you run an app on Supabase, you need to know which parts apply to you and which parts are the researchers' interpretation.
What the Study Actually Measured
UpGuard's method started from roughly 300,000 unique domains showing indicators of Supabase use, taken from BuiltWith and the Chrome UX Report. It fingerprinted them by looking for Supabase key names in public JavaScript files, then queried each domain for a users table. 16,326 databases exposed readable tables. This is the kind of request any developer can send to the Supabase REST API with the public key, not a sophisticated attack.
Supabase's own documentation explains why a table can be readable: a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Once RLS is enabled, no data is accessible with the publishable key until you create policies, so an overly broad policy can also expose data. The 16,326 figure counts databases with readable tables. It is not a count of confirmed breaches of production apps.
UpGuard also discusses a related failure: public keys placed in client-side code and then used as if they were secret keys. Separately, Supabase documents that its secret (service_role) key bypasses RLS, so it must never appear in a browser bundle. A project can have every table correctly protected and still be exposed that way.
Where the Study Makes Inferences
UpGuard connects the exposure to AI-driven development, saying these sites are created by AI coding agents and the humans are unaware of the configuration. That is the authors' interpretation. The method described fingerprints Supabase usage from public JavaScript, not the tool that wrote the code, so the study does not show which of the 16,326 were AI-built and which were hand-built without RLS.
This distinction matters for how you read the number. It does not make the finding less serious. Tables without RLS are publicly readable whether a human or an agent created them. But the study does not prove that AI-built apps are disproportionately exposed compared to apps built without AI tools. It proves that 16,326 Supabase projects had publicly readable tables, which is a significant and concrete finding on its own.
Zovintra commentary on the UpGuard study: the finding that 16,326 databases had publicly readable tables is real and documented. The causal link to AI tools specifically is the authors' inference, not a measured result.
Why the Default Behaviour Is the Root Cause
UpGuard notes that tables created programmatically through the API do not have RLS enabled. Supabase's documentation tells developers to enable RLS on every table in an exposed schema, which makes it an explicit step rather than something you get for free. Any table without a deliberate policy decision is a candidate for being readable.
AI coding tools create tables faster than they add security policies. Human developers also skip this step when moving quickly. The pressure to ship and the focus on making features work produce the same outcome: tables that were never explicitly secured. The UpGuard number reflects the cumulative effect of that pattern across the developer community.
The detailed explanation of how agent-created tables skip RLS covers the mechanism specifically. That post is worth reading if you used a coding agent to create your schema and have not verified your policies.
What Type of Data Was Actually Exposed
UpGuard did not publish a full breakdown of every exposed database, but it gave examples. One India-based site exposed a users table of 65,467 people and over 100,000 private messages. A US valet service exposed about 100,000 customers, including roughly 43,000 emails and 78,000 license plates. A Canadian relocation service exposed about 5,000 records including 884 plaintext passwords. UpGuard says over half of the databases had indicators of some personal data, a smaller share included passwords or authentication tokens, and very few showed plausible credit card data.
Read these as examples of what a readable table can hold, not as a profile of all 16,326 projects. The article does not say how many were test or development projects, so treat any claim about the production share with caution.
What This Means If You Use Supabase
The study does not reveal whether your specific app is affected. It reveals that a large number of Supabase projects share the same misconfiguration and that the pattern is common enough to find at scale through a straightforward API scan. Your app may or may not be in the affected group.
The check is simple: open your Supabase dashboard, go to the Table Editor or Authentication > Policies, and verify that RLS is enabled and at least one non-permissive policy exists for every table containing user data. A table with RLS enabled and no policies is safe (it denies all access), but you need to also verify that your application is not using USING (true) as a policy, which grants access to everyone.
If you used a coding agent to build your schema and have not run a security review, treat your tables as unprotected until you check each one. Our free code review tool scans your codebase for Supabase configuration issues, including exposed tables and leaked keys, and produces a prioritised findings report. You do not need a developer to run it.
The Service Role Key Problem Is Separate
The service_role key is not the same as the public key. Supabase's documentation says it bypasses RLS and must never be used in the browser or exposed to customers. If it appears in client-side JavaScript, any visitor can extract it and read or write any table.
AI tools that generate Supabase client setup code can pick the wrong key, particularly if the prompt asks for full database access. Search your codebase for the string 'service_role' and confirm it only appears in server-side code or environment variables that are never sent to the browser. This check takes five minutes.
Reading the Study Without Overreacting or Underreacting
The number 16,326 is large enough to indicate a systemic problem, not a few isolated incidents. The scan used routine requests to publicly reachable endpoints, which is why the finding matters regardless of whether AI tools caused it.
At the same time, the study does not mean that Supabase is insecure or that every app built on it is exposed. It means that a specific, avoidable misconfiguration - RLS not enabled on tables created through the API - has been left in place on a large number of projects. Every affected project can fix it with a few SQL statements.
If you want to know whether your app is affected, the AI-built app security checklist covers twelve checks including RLS status, service_role key exposure, and storage permissions. Running those checks before any real users arrive is significantly cheaper than running them after an incident. If you want a second set of eyes on the results, our Launch and Rescue service is structured exactly for that.
Common questions
What did the UpGuard Supabase study actually find?
UpGuard reported 16,326 Supabase databases with publicly readable tables, out of roughly 300,000 candidate domains scanned. That figure counts databases with readable tables. It is not a count of confirmed breaches of production apps.
Does the UpGuard study prove AI-built apps are more exposed?
No. The method fingerprinted Supabase usage from public JavaScript, not the tool that wrote the code. The link to AI coding agents is the authors' inference, not a measured result. Tables without RLS are readable whether a human or an agent created them.
How do I know if my own Supabase app is affected?
Verify in your dashboard that RLS is enabled and a non-permissive policy exists for every table with user data, and search your code for service_role. If you want a second set of eyes, Zovintra's Launch and Rescue service is structured for that.
Sources
- Everything, Everywhere: Systemic Data Exposure in Supabase Apps - UpGuard, 14 Oct 2026
- Row Level Security - Supabase Docs - Supabase, accessed 19 Oct 2026
