A runnable reproduction of the Next.js + Supabase RLS leak (red on one branch, green on the other, ~2s)

[cekuu35]

If you ship Next.js on Supabase, the authorization boundary lives in Postgres rather than in your route handlers, and it fails in a way the App Router will never show you: the page renders, the query succeeds, and it returns rows that belong to somebody else.

I built a minimal reproduction of the most common version of that, because arguing about it in the abstract goes nowhere.

The fixture — MIT, no Docker, no cloud project, no credentials. It runs Postgres in PGlite, so it is npm ci and about two seconds:

https://github.com/cekuu35/supabase-rls-leak-demo

npm ci && npm run test:ci

Two branches, byte-for-byte identical test files, differing only by one policy file. broken gives you 4 failed / 1 passed, fixed gives you 5 passed. The failure prints the actual leaked row, so it is obvious what happened rather than being an assertion count.

Three Next.js-specific things that come up around it

process.env.SUPABASE_SERVICE_ROLE_KEY is not inlined into your client bundle — the docs are explicit that non-NEXT_PUBLIC_ variables stay server-side. What does reach the browser is a value you hand across the boundary yourself, e.g. a Server Component passing it as a prop to a 'use client' component, because that goes into the RSC payload. A grep of .next/static will not find that one; you have to look at the rendered response.

RLS policies are a performance surface as well as a security one. auth.uid() = user_id is re-evaluated per row; (select auth.uid()) = user_id becomes an InitPlan evaluated once. Supabase's own benchmarks put the worst case at 178,000ms → 12ms, and the dashboard's Advisors → Performance tab lists every instance for you under auth_rls_initplan.

A policy that exists is not a policy that runs. If RLS was never enabled on the table, the policy rows still sit in pg_policies and nothing is enforced — which reads as configured in every UI you look at.

Disclosure, since two of the links are mine to sell: the fixture above and a 10-check pre-ship PDF are free with no email wall. I also sell a $29 kit that packages the same audit as seven commented SQL files you run against your own catalogs, and I do the audit as a service. Run the free Supabase linter first — if it comes back clean and the query in the repo agrees, you are done and you have spent nothing.

• Free fixture: https://github.com/cekuu35/supabase-rls-leak-demo
• Free PDF, no email wall: https://cengokurtoglu.gumroad.com/l/nextjs-supabase-10-checks-free
• $29 kit: https://cengokurtoglu.gumroad.com/l/supabase-rls-audit-kit

Happy to look at a specific policy if anyone wants to paste one.

[Bhanuteja005]

Ran the fixture. Clean repro, and the PGlite choice is right — no credentials
means people will actually run it.

Two notes on the write-up, then two cases the fixture doesn't cover that fail
the same way.

On the benchmark number. The 178,000ms → 12ms figure is from
GaryAustin1/RLS-Performance, which Supabase links rather than publishes.
Supabase's own docs state "over 100x on large tables" for the indexing fix. Worth
attributing to the test repo directly. The mechanism as you describe it is
correct, with one caveat the docs flag: wrapping in select is only valid if
the function's result doesn't depend on row data.

TO authenticated is missing from the framing. A policy with no role clause
is also evaluated for anon. Supabase's own RLS prompt recommends specifying
the role so the policy never executes for unauthenticated requests — it's both a
correctness and a performance fix, and it composes with the (select ...) point.

---

Case 1: SECURITY DEFINER views. A view over the protected table runs as its
owner, so base-table policies are bypassed entirely. pg_policies looks
identical either way — same "configured in every UI" failure your third point
describes. Fix is alter view v set (security_invoker = on) on PG15+. Supabase's
linter reports it as security_definer_view.

Case 2: caching above Postgres. This one is Next-specific and RLS structurally
cannot catch it. Put a user-scoped query inside use cache / unstable_cache,
or let the route render statically, and Postgres returns the correct rows for
whoever populated the cache and Next serves them to everyone after. Policies are
correct, query is correct, leak is in the framework.

Calling cookies() opts the route into dynamic rendering and covers the common
path, but not a cached function that takes the user id as an argument:

// leaks: cache key doesn't include the caller's identity in any way
// that RLS can see, and the DB is never consulted on the second call
const getDocs = unstable_cache(async (uid: string) => {
  return supabase.from('documents').select()
}, ['docs'])

That would be a strong fifth test — red on both branches, since no policy file
fixes it.

Minor, on the env-var point: import 'server-only' at the top of the module
holding the service-role client turns the accidental-client-import case into a
build error rather than something you have to find in a rendered response.
taintUniqueValue catches the prop-passing case you describe.

Happy to open a PR with the view case and the cache case if you want them in the
fixture.