# What a repo check found in 25 public Supabase repos (November 2026)

We ran a repository check on 25 public GitHub repos that keep Supabase migrations in `supabase/migrations`, then checked every critical finding by hand. These numbers come from our own run on 2026-11-02 and are not in any provider's documentation.

## Short answer

- **8 of 25 repos (32%)** have a policy that lets anyone, signed in or not, write every row of a table: a write policy whose condition is just `true`.
- **4 of 25** create a public table and never enable row level security in any migration. **3 more** grant table access to the Data API roles on a table without RLS.
- **13 of 25 (52%)** have a `security definer` function in `public` that no migration closes to `anon`. That is a warning, not proof of a hole: what the function does decides the risk.
- **15 of 25 (60%)** have a `using (true)` read policy. That is right for public content and wrong for anything per-user, so it is a warning.
- **24 of 25** still read the legacy `anon` key name, which Supabase's move to publishable and secret API keys asks projects to review.
- **Precision:** 15 of the 16 critical findings held up when checked by hand (94%).

## Method

- **Sample:** 25 repos drawn at random (fixed seed) from a list of public GitHub repos with a `supabase/` folder. Repos over 60 MB were skipped. Each was shallow-cloned and read only; no app was run and no database was contacted.
- **Check:** `npx -y viberaven check --json` and `npx -y viberaven changes --json` (VibeRaven 1.7.7), in each repo root.
- **Review:** every critical finding was opened and judged by hand against the migration or file it names. Repos are not named here.

## Results

| Finding | Repos (of 25) | Severity | What it means |
| --- | --- | --- | --- |
| `rls_policy_allows_all_write` | 8 | critical | A policy lets anyone write every row of a table |
| `rls_disabled` | 4 | critical | A public table is created and RLS is never enabled in a migration |
| `data_api_grant_without_rls` | 3 | critical | The Data API roles are granted a table that has no RLS |
| `service_role_key_in_client_code` | 1 | critical | The service role key is used in code that ships to the browser |
| `security_definer_function_executable` | 13 | warning | A `security definer` function in `public` stays callable by `anon` |
| `rls_policy_allows_all_read` | 15 | warning | Anyone can read every row; fine only for public content |
| `env_var_drift` | 19 | warning or info | Code reads env vars that `.env.example` does not list |
| `pooler_port_mismatch` | 4 | warning | Serverless code connects on 5432 instead of the 6543 transaction pooler |
| `public_debug_endpoint` | 2 | warning | A diagnostic API route returns env or request internals |
| Legacy `anon` key name | 24 | review | Supabase publishable and secret API keys change |

## Precision, before and after

The first run, with 1.7.6, raised 20 critical findings, and 14 held up (70%). Five of the six that did not came from four causes:

- a file named `auth.js` was read as the Auth.js library;
- React Native's versioned `ios/.xcode.env` was read as a credential file;
- the grants check compared migrations from two folders by file order, though only timestamped names give an order;
- a `security_invoker` view was asked for its own grant.

VibeRaven 1.7.7 fixes all four. On the same 25 repos it raises 16 critical findings, and 15 hold up (94%).

## Limits

- This is a repository check. It reads migrations and code, not the live database. A policy changed later in the Supabase dashboard does not show here.
- 25 repos is a small sample, and a public repo is not always a production app.
- A clear result is not a security audit.

## Check your own repo

In the project root:

```bash
npx -y viberaven check
```

It is free, runs locally, and needs no account. In a coding agent, ask it to "check this with viberaven".

## Related

- [Find Supabase tables missing RLS](https://viberaven.dev/find-supabase-tables-missing-rls)
- [Supabase policy using (true)](https://viberaven.dev/supabase-policy-using-true)
- [Security definer function callable by anon](https://viberaven.dev/supabase-security-definer-function-anon)
- [Supabase Data API grants after October 30](https://viberaven.dev/supabase-october-30-data-api-grants)
- [Site index for agents](https://viberaven.dev/llms.txt)