Last updated: 2026-10-03
On September 24, 2026, UpGuard Research published "Everything Everywhere: Systemic Data Exposure in Supabase Apps", a study by Greg Pollock of databases on Supabase, a hosted Postgres service. Web and app front ends query Supabase directly with a key that is public by design (the anon key, now the publishable key). UpGuard reports: "Across the candidate set we identified 16,326 databases exposing readable tables," and attributes the exposure to row level security (RLS) that is missing or misconfigured on the tables.
How did UpGuard find 16,326 readable databases?
UpGuard collected "~300,000 unique domains with indicators of Supabase usage" from BuiltWith and the Chrome UX Report dataset, then queried each for a table named users. Where that table was missing but some data was accessible, the database answered with a "hint" naming an accessible table. UpGuard classified the exposed tables by schema rather than reading every row: "Over half of the databases had indicators of some PII. A smaller percentage included passwords or authentication tokens."
UpGuard opened a handful to confirm real data. One belonged to a US valet service with over 100,000 customer phone numbers and about 78,000 license plate numbers; a Canadian immigration and relocation service stored 884 plain-text passwords in a table of nearly 5,000 user records. UpGuard says it notified owners where it found a significant exposure.
The sample is websites. UpGuard set out "to identify standalone websites operating on their own primary domains" and fingerprinted them "by looking for Supabase key names and databases addresses in public Javascript files." The study gives no count of iOS or Android apps, so the mobile share of the 16,326 is unmeasured.
Why is the Supabase anon key public?
The anon key identifies the project; RLS policies in the database set what each request may read. Supabase's API keys documentation lists the publishable key as "Safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code," and names "Mobile or desktop applications, where the key is bundled inside the compiled packages or executables" as public environments. The same page states that Supabase is "deprecating the anon and service_role keys by the end of 2026," and that legacy keys stay valid until a project owner disables them.
| Key | Format | Where Supabase places it | What a copy in a shipped app means |
|---|---|---|---|
| Publishable | sb_publishable_... |
Web pages, mobile and desktop apps | Expected; access is limited to what RLS allows |
| anon (legacy) | JWT, begins eyJ |
Same as publishable | Expected; access is limited to what RLS allows |
| Secret | sb_secret_... |
Backend only | Full access; "bypasses every Row Level Security policy" |
| service_role (legacy) | JWT, begins eyJ |
Backend only | Full access, same as a secret key |
Source: Supabase API keys documentation, opened 2026-10-03.
Where is row level security off by default?
UpGuard: "Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default." Supabase's 2025 security retrospective, dated January 7, 2026, states: "For tables created via the dashboard, RLS is enabled by default." For tables created with external tools or migrations, Supabase documents Postgres event triggers that enable RLS on creation, and it emails project owners when a table is created with RLS disabled.
Supabase's chief information security officer, Bil Harmer, told TechCrunch on September 25, 2026, that the company had not seen the research and its projects are "secure by default," adding: "We provide secure defaults and tooling, and customers control how their own projects are configured."
What earlier Supabase exposures does UpGuard cite?
UpGuard cites six, including CVE-2025-48757 (published May 30, 2025), which describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that let unauthenticated attackers read or write tables of generated sites; the record notes that Lovable disputes it. The researcher's statement counts 170 of 1,645 Lovable projects with inadequate RLS and notes that "Supabase provides public anon keys by design." On February 2, 2026, Wiz reported a Supabase API key in Moltbook's client-side JavaScript that gave read and write access to a database containing "1.5 million API authentication tokens, 35,000 email addresses."
What does an app binary contain?
A mobile app that queries Supabase from the device uses the two kinds of value UpGuard searched for in JavaScript: the project URL, https://<project-ref>.supabase.co, and a publishable or anon key. Supabase's Security Advisor checks RLS configuration from the owner's side; lint 0013 is "rls disabled in public."
When I scan an Android app, the report records every URL host found in the dex files, the resources, a React Native bundle or a Flutter Dart snapshot, each with its file and line, including a <project-ref>.supabase.co host. The key extractors record named formats (Google, AWS, Stripe, Sentry) with the value as found; I locate a Supabase anon or publishable key by reading the decompiled files. A PostgreSQL connection URL with an embedded password in the dex or resources, the credential for a direct database connection, is a high-severity finding with its value.
A traffic capture on a test device shows the requests the app sends to the project's /rest/v1/ endpoints, the table names in those requests, and what the database returns to the app's own session. I do not query any app's database; whether a table is readable to anyone with the key is outside what a scan and a capture establish. What a scan checks and the limits of a scan are on the methodology page. An earlier post covers an SDK flaw inside the app: the EngageLab push SDK's exported activity.
I run these investigations for lawyers and for researchers working with lawyers, on one app or a list in bulk. Sign up for a CanITrustThat account to run your own research, let us run an investigation for you, or browse the scanned apps.