The short answer
Thousands of apps built on Supabase leak data because their tables have no row level security, not because Supabase was hacked. The public API key sits in every front end by design, so row level security (RLS) is the only thing between that key and your users’ records. Teams building on Supabase should treat RLS as a release blocker, not a later hardening step.
The pattern is familiar. Open S3 buckets and public GitHub repos leaked data the same way until the defaults changed.
What did UpGuard find?
UpGuard used BuiltWith technology fingerprints and the Chrome UX Report dataset in BigQuery to find about 300,000 domains that load Supabase code. For each project, researchers asked the database for a “users” table with the same public key a browser would use. No exploit or password guessing was involved. In 16,326 cases, the database returned readable tables.
The examples are not small. A US valet parking service exposed more than 100,000 customers’ phone numbers, license plates and visit history, plus 665 staff records. A Canadian immigration coaching service leaked about 5,000 records, including 884 passwords stored in plain text. An adult streaming platform in India exposed 65,467 users and more than 100,000 private messages. An African government consulate in France exposed addresses of about 25,000 people, and a virtual SIM farm leaked more than 100,000 text messages, most of them one-time passcodes.
Supabase, valued at $10 billion earlier this year, did not dispute the findings. CISO Bil Harmer told TechCrunch that “security at Supabase is never finished” and that the company will keep making it easier for every developer to ship securely.
Why do AI-built apps leave tables open?
Supabase exposes your Postgres database through an auto-generated REST API. The front end talks to it with a public “anon” key that anyone can copy from the browser. That design is safe only when every table in an exposed schema has RLS turned on and policies that limit rows to the right user.
In March 2025, Supabase made RLS the default for tables created in its Table Editor. But tables created through the API or raw SQL migrations, which is how coding agents like Claude Code, Cursor, Bolt and Lovable build a schema, still start without it. The agent writes the table, the app works in the demo, and nothing warns the founder that the same table answers anyone who asks. UpGuard notes that earlier, smaller studies found exposure rates of 28 to 39 percent of sampled Supabase apps.
What it means for US & EU software teams
First, “it works” is not a security test. An AI agent optimizes for a working feature. Access control is a negative requirement: it only shows up when someone tries to read data they should not. If your team or your vendor ships an MVP with an AI coding agent, add an explicit check that every table has RLS and a policy before any real user data goes in.
Second, the public key changes the threat model. With a classic backend, a forgotten permission sits behind your own API. With Supabase, the database itself is on the internet. One missing policy is a data leak, not a bug.
Third, this is a compliance event, not only a technical one. Readable tables with names, phone numbers or passwords are a personal data breach under GDPR, with a 72-hour window to notify the regulator once you know. US state breach laws, and HIPAA for health data, add their own duties. You cannot answer “did anyone read it?” without API logs, so keep them.
How do you check your Supabase project?
- List tables without RLS. Open the Security Advisor in the Supabase dashboard, or query
pg_tablesfor the public schema and list every table whererowsecurityis false. Treat each one as exposed until proven otherwise. - Enable RLS and write real policies. Turning RLS on with no policy blocks all access; turning it on with a policy like “true” blocks nothing. Scope rows to
auth.uid()or a tenant ID. - Test like an attacker. Take the anon key from your own front end and query each table from outside the app. Sensitive tables should return nothing.
- Keep the service key server-side. The service role key bypasses RLS. It must never appear in client code, mobile builds or public repos.
- Put the rule into your pipeline. Add a CI check that fails any migration creating a table without RLS, and tell your coding agent in its instructions that every new table needs a policy.
- If data was readable, rotate and review. Reset exposed passwords and tokens, check API logs for reads you did not expect and decide with counsel whether breach notification applies.
Frequently asked questions
What did UpGuard find in Supabase apps?
In research published on September 25, 2026, UpGuard scanned roughly 300,000 domains that showed signs of using Supabase and found 16,326 databases with tables anyone on the internet could read. More than half showed signs of personal data such as names, emails, phone numbers and addresses. A smaller share exposed passwords or authentication tokens.
Was Supabase itself hacked?
No. UpGuard did not report a breach of Supabase infrastructure. The exposures come from how customers configured their own projects, mainly tables without row level security or with weak policies. Supabase says projects are secure by default and that security is a shared responsibility with customers.
Why are AI coding agents part of the problem?
Since March 2025, Supabase turns on row level security by default for tables created in its dashboard Table Editor. Tables created through the API or raw SQL, which is how coding agents such as Claude Code, Cursor, Bolt or Lovable usually work, do not get it automatically. If the agent never writes the policy, the table stays readable with the public key shipped in the front end.
How do I check whether my Supabase project is exposed?
Open the Security Advisor in the Supabase dashboard and look for tables with row level security disabled in exposed schemas. You can also run a query against pg_tables for the public schema and list every table where rowsecurity is false. Then test with the public anon key from outside your app, as an attacker would, and confirm that each sensitive table returns nothing.
What should I do if personal data was readable?
Enable row level security and write policies first, then rotate any exposed passwords, tokens and keys. Review API logs to see whether anyone read the data. If personal data of EU residents was exposed, GDPR may require notifying the regulator within 72 hours of becoming aware of a breach, and US state breach laws can require notifying affected people.
Sources
UpGuard — Everything Everywhere: Systemic Data Exposure in Supabase Apps (September 25, 2026)
TechCrunch — Some Supabase customers are publicly exposing reams of people’s data to the web
Cybernews — 16,000 Supabase databases exposed as vibe-coded apps leak sensitive user data