Build1 publisher3 min readPublished
Supabase's new API default skips the existing tables behind UpGuard's 16,326 readable databases
UpGuard found 16,326 Supabase databases with readable tables in a scan of roughly 300,000 domains. Supabase's new default keeps new tables off its APIs, but older tables keep their grants until owners review them and their row-level security.
The Engineer · Build desk
What happened
- UpGuard scanned roughly 300,000 domains showing signs of Supabase use and found 16,326 databases where at least some tables could be read.
- More than half of those databases showed indicators of personal information, and smaller numbers showed indicators of passwords or authentication tokens.
- UpGuard traces many of the exposures to absent or weak row-level security policies, or to tables that stayed publicly queryable.
- Supabase's change to default API grants applies to new tables, and the company says existing tables keep the grants they already have.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Once enforcement reaches existing projects on October 30, the exposed tables UpGuard counted will shrink only as their owners change grants or policies by hand.
- decision Teams whose coding agents create tables in code have to write and test row policies for each table before exposing it, since the grant default governs reachability only.
- contradiction Supabase's security chief calls projects secure by default, while UpGuard says programmatically created tables start without RLS, a case a team on the new grant default can still hit.
A Supabase table can be read from outside only when two separate controls both allow it. The first is whether the automatically generated Data API can reach the table at all. That API lets applications query tables over HTTP [9]. The second is row-level security, the policy layer that decides which records a given role gets back [17]. The API key embedded in client-side code is not necessarily a secret credential, and its presence alone does not establish a vulnerability [11]. What the key retrieves depends on the access rules around each table [11].
Supabase's change works on the first control. Its April 28 changelog let new projects opt out of automatically exposing new tables in the public schema through the Data and GraphQL APIs [12]. On May 30 that behavior started becoming the default for new projects, in a gradual rollout over several weeks [13]. Existing projects are scheduled for enforcement on October 30 [14]. In my view, withholding API access from a new table until someone grants it is the right default.
The link to AI tools runs through the second control. According to UpGuard, tables created programmatically, the route coding agents commonly use, do not enable RLS by default [16]. Say an agent creates a table in code and a developer later grants the API access to it on purpose. The result is a table whose rows are governed by no policy, reachable with the client key. Supabase's grant change does not remove the need to configure row-level access in that case [17].
UpGuard's 16,326 is about 5.4% of the roughly 300,000 domains it started from [1], though a domain and a database are not the same unit. The researchers probed for a commonly named "users" table and judged what data could be present from table names and schemas, without inspecting every record [5]. A table called users is a reasonable first guess, for researchers and for anyone else. UpGuard's own figures on personal data do not agree. The "more than half" figure implies more than 8,163 databases [2]. UpGuard separately told TechCrunch that about 16,000 databases had some degree of personal data exposed [4], roughly 98% of the readable set [3].
The named examples include a database associated with a consulate of an African government in France and one a virtual SIM service used to handle one-time passcodes [7]. The findings are not evidence that every exposed database was misused [8].
Supabase Chief Information Security Officer Bil Harmer told TechCrunch the company had not seen UpGuard's research [18]. He described projects as "secure by default" [19]. He said security is shared between Supabase and customers, who control how their projects are configured [20].
On a project older than the May 30 rollout [13], I would run the check in this order:
1. An inventory of every public-schema table the Data API can reach, including tables that predate the new default [9][15]. 2. RLS confirmed on each of those tables, starting with any an agent created in code [16]. 3. A query against each table using the key that ships in the client, compared with what the policy is meant to return [11][17].
What to watch
- Whether Supabase changes the RLS default for tables created programmatically, the path UpGuard ties to coding agents.
- Whether UpGuard publishes record counts or reconciles its 'more than half' and 'about 16,000' personal-data figures.
- Whether the October 30 enforcement ships on schedule and whether Supabase extends it to grants on tables created before that date.