DEV Community: Cenk KURTOĞLU

I Found 60+ Live Supabase Keys in Public Repos, So I Benchmark Whether LLMs Can Spot Them

Cenk KURTOĞLU — Wed, 30 Sep 2026 18:23:17 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

As part of my day-to-day security work, I scan public GitHub repos for committed Supabase credentials. In three days of scanning I found 60+ live service_role keys — keys that bypass Row Level Security entirely and give full read/write access to real production databases. Real finds include:

config.php files with hardcoded service_role keys (a CRM, an LMS, a driving school's backend)
.env.example templates where someone pasted a real key instead of a placeholder
NEXT_PUBLIC_-prefixed service_role keys — which means the key ships in the browser bundle to every visitor
A docker-compose.yml committing three secrets at once: DB password, anon key, and service_role key
Deploy docs (DEPLOY.md, RAILWAY_ENV_SETUP.md) with full credentials "for convenience"

That got me wondering: the people leaking these keys are often using AI assistants to write this code. Can the models themselves spot what they helped commit? So I built a benchmark on Kaggle Benchmarks that treats models like a security reviewer: given a realistic file snippet, triage it — is there a service_role key (critical), an anon key (medium), a DB password, or nothing (placeholder/docs-only)?

The 10 cases are all modeled on real leak patterns I actually found (every key in the benchmark is a fake, structurally-valid JWT):

Hardcoded service_role + anon in PHP config
.env with a single anon key
Client-side createClient() fallback with anon key
Deploy doc with service_role key + DB password
Docs with placeholders only (the false-positive trap)
NEXT_PUBLIC_ service_role fallback in a client file — bundles into the browser
.env.example left with a real service_role key
Commented-out "old key kept for reference" — still a live secret
Two keys side by side (anon + service_role) — models must classify both correctly
A base64-obfuscated service_role used in a bash script — requires two-step decoding

Each model answers a strict JSON verdict (has_service_role, has_anon, has_db_password, warning_level, reasoning) and the task asserts every field. Score = fraction of cases fully correct. Temperature 0. One submission per participant, so I made the cases count.

Models Tested

Nine models from the Kaggle Benchmarks suite, picked to cover the spectrum developers actually choose between — frontier flagships, cheap/fast workhorses, and open-source reasoning models:

anthropic/claude-sonnet-5
google/gemini-3.7-flash
google/gemini-3-flash-preview
google/gemini-3.1-flash-lite-preview
openai/gpt-5.4-nano
openai/gpt-oss-120b
deepseek-ai/deepseek-r1-0528
qwen/qwen3-next-80b-a3b-instruct
ibm/granite-4.0-h-small

If your AI assistant is one of these, this is literally a test of "would my assistant catch its own leak?"

Findings

Model	Score	Notes
claude-sonnet-5	10/10	Clean sweep
gemini-3.7-flash	10/10	Clean sweep
gemini-3-flash-preview	10/10	Decoded the base64 blob mid-response to find the role claim
gemini-3.1-flash-lite	10/10	Clean sweep, cheapest tier to do it
gpt-5.4-nano	8/10	Missed the commented-out key + the base64 obfuscation
deepseek-r1-0528	0/10	Flagged everything critical — see below
qwen3-next-80b	partial	Passed 5/6 assertions before rate-limiting out
gpt-oss-120b	—	Errored repeatedly (provider 429 under load; excluded from comparison)

The headline: modern models are scarily good at the obvious cases

On the five "classic" cases (hardcoded config keys, docs with credentials, placeholder-only false-positive traps), every frontier model scored perfectly. Even gpt-5.4-nano — the cheap, fast one — went 5-for-5. If you paste a file with SUPABASE_SERVICE_ROLE_KEY=eyJ... into any of these models and ask "is this bad?", they will all tell you correctly: yes, critical, rotate it.

The interesting part is where they diverge

DeepSeek-R1, a dedicated reasoning model, scored 0/10 — but not because it missed the keys. It flagged everything: every file, including the placeholder-only DEPLOY.md, came back "critical, service_role present, DB password present." In security triage, a reviewer who cries critical on every file gets ignored on the one that matters. Recall without precision is just alarm fatigue with extra steps.

The edge cases did their job. gpt-5.4-nano missed exactly the two sneaky ones: the commented-out "old key kept for reference" (it treated the comment as dead code — but commented secrets still work, and old keys often still rotate back into service) and the base64-obfuscated key. The frontier models — including the cheap Gemini Flash tiers — caught all ten, with Gemini 3 Flash visibly decoding the base64 blob mid-response to identify the role claim before answering.

What this means in practice

Your AI assistant will not save you from committed secrets — but it can. Every model tested can catch these leaks instantly when asked. The problem is nobody asks. Secrets get committed because the review step never happens.
Over-flagging is its own failure mode. A reviewer (human or AI) that cries "critical" on every placeholder teaches teams to ignore alarms. Precision matters as much as recall in security triage.
The 15-minute fix beats any detector. Rotate the key in the Supabase dashboard (dies instantly), move it to env vars, git filter-repo if you want it out of history.

What I'd measure next

Tool use: give the models a repo tree and a search tool, and see if they actively hunt for secrets rather than judging a pasted file
Multi-file context: the real-world version of this leak is spread across config.php + deploy docs + docker-compose — does performance drop when the secret is two hops away?
Fix quality: flagging is step one; does the model produce a correct remediation (rotate first, then remove, then history-clean)?

Run the same checks on your own app

The 10 cases above are one snapshot. Your codebase will have its own version.

I put nine read-only Postgres queries that cover the same failure classes into a free file - nothing leaves your database, you run it in your own SQL editor:
github.com/cekuu35/supabase-rls-leak-demo - audit/rls-audit.sql

The same repo has a red/green test suite that demonstrates a cross-tenant leak and the one-file fix.

If you want the full guided version - write-side checks, a role-simulation harness, and remediation templates you can drop into an existing repo - that's the Supabase RLS Audit Kit. It runs entirely against your own catalogs, $29.

Disclosure: both links are mine. The audit queries and demo are free and MIT licensed.

My Benchmark

Task: committed-supabase-key-detection on Kaggle

The task page shows per-model results, full conversations, and the assertion breakdown for every case. Fake keys, real patterns — steal the cases for your own review checklists.

(And if you're reading this with a committed Supabase key somewhere in your repo history: rotate it now. It takes 15 minutes, and I promise you're not the only one who's seen it.)

58 of 154 public Supabase apps had a working service_role key in git

Cenk KURTOĞLU — Thu, 24 Sep 2026 09:12:40 +0000

58 of 154 public Supabase apps had a working service_role key in git. Here's what that means for yours.

If you build with Lovable, Bolt, Cursor, or any AI coding tool on top of Supabase, this week's scan has a number you should see: 58 of 154 public apps shipped a working service_role key inside their git history.

That key is the master key for the database. It bypasses Row-Level Security entirely — the same RLS you turned on in the dashboard does not apply to it. Anyone who finds it can run DELETE FROM "user" over the REST API and the database believes it.

I did not read a single row of anyone's data. I verified the key decodes to a real project (iss, ref, and a service_role role claim), checked that the project is live, and moved on. That is enough to know the exposure is real.

Why this keeps happening (it is not laziness)

Three causes, in the order I actually saw them:

AI tools scaffold .env files with real keys. Your AI agent opens the Supabase dashboard to "wire up the database," copies the project URL and keys into .env, and commits it because the app "won't build" otherwise. The placeholders in memory get replaced by real values — then .gitignore is never created for .env.
The file that ships is named like a dev file. .env.txt, env.local, .env.development — these often bypass the .gitignore pattern *.env because the name is subtly different.
History keeps the key after the file is deleted. Deleting .env in a new commit is not a fix. The key stays in every previous commit unless you rewrite history.

The 10-second check for your own repo

Paste this into supabase.com/dashboard → your project → SQL Editor. It shows every object a service_role (or anon) key can reach that your RLS policies do not actually protect:

select n.nspname, c.relname, c.relrowsecurity
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where c.relkind in ('r', 'p')
  and n.nspname = 'public'
  and not c.relrowsecurity
order by n.nspname, c.relname;

Every row of that result is readable and writable by anyone holding the public anon key that ships in your browser bundle. If relrowsecurity is false, Row-Level Security is not even on for that table.

For git: git log --all --oneline -- .env shows every commit the file touched. If you see more than the one "deleting it" commit, the key is still in history.

If you find one — do this first

Rotate the key first (dashboard → Settings → API), then rewrite history (git filter-repo or BFG).
Fix the commit habit that caused it: one line in your AI tool's instructions — "never commit .env, create .gitignore entry *.env* before first launch."
Re-run the check above on the same project to make sure nothing else is open.

Every check in that list — RLS coverage, open policies, USING (true) traps, write-without-read policy conflicts, and the git-history secret scan — I've packaged as a free, read-only, 60-point pre-launch check that runs against your own DB in about 30 seconds and uploads nothing:

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

The scan behind this post ran the same evidence standard: decode the JWT, confirm role == "service_role", confirm the project is live. No data was read, no exports were made, nothing was saved. If you want a second pair of eyes on your schema after rotating — policy conflicts, unisolated joins, service_role exposure paths — that is the read-only review I do as paid work, and the email + Gumroad link are in my profile.

Supabase RLS: a small, evidence-first pre-launch check

Cenk KURTOĞLU — Fri, 18 Sep 2026 21:34:19 +0000

Supabase RLS: a small, evidence-first pre-launch check

RLS being enabled is only the first check. A useful review asks what an anonymous request, an authenticated user, and a second tenant can actually read or write.

Five checks worth running

List every exposed table and confirm RLS is enabled.
Inspect both USING and WITH CHECK; a read policy does not automatically secure inserts or updates.
Look for policies that are intentionally broad, such as USING (true), and confirm they are limited to the correct role and table.
Review SECURITY DEFINER functions, their search_path, and their EXECUTE grants.
Test the live database with two separate user identities. Confirm that user A cannot read or modify user B's rows, even when the request is made directly against the REST endpoint.

Example owner-scoped policy:

alter table public.orders enable row level security;

create policy "orders_select_own"
on public.orders
for select to authenticated
using (auth.uid() = user_id);

create policy "orders_insert_own"
on public.orders
for insert to authenticated
with check (auth.uid() = user_id);

Use a service-role key only in a trusted server-side path. Never put it in browser code, migrations, screenshots, or a public issue.

The free RLS isolation fixture demonstrates the two-user negative-test pattern. If you want a human second set of eyes, the 24-hour, three-table review is a focused configuration review using sanitized schema and policy SQL only.

This is a configuration review, not a penetration test or a security certification. Test only systems you own or are explicitly authorized to review.

October 30, 2026: the Supabase change that will 42501 your next deploy - and the leak that was already there

Cenk KURTOĞLU — Tue, 08 Sep 2026 11:06:58 +0000

On October 30, 2026, Supabase changes what happens to every table you create in an existing project. Not a setting you toggle - a platform default enforcement that lands on every project at once.

Here is the quiet part nobody warns you about: the migration you already wrote and shipped is the one that breaks, and the leak that matters was probably already there before today.

What actually happens on October 30

Supabase published this as changelog entry #45329 on April 28, 2026. The dates:

Date	What changes
2026-05-30	New projects default to opt-in exposure (grant required)
2026-10-30	The same rule is enforced on every existing project

Before the change, a table in public was automatically granted select, insert, update, delete to anon, authenticated, and service_role - reachable through the Data API the moment it existed. After the flip, new tables in public are reachable only if your migration explicitly GRANTs the role.

Existing tables keep their current grants. That is the trap, in two opposite ways:

Trap 1 - your next migration breaks with a 403 that is silent in CI.

create table invoices (
  id uuid primary key default gen_random_uuid(),
  customer_id uuid not null,
  amount_cents integer not null,
  created_at timestamptz default now()
);

Deploy that after October 30 and the first SDK call dies in production with error 42501 permission denied for table invoices - PostgREST short-circuits at the privilege layer before RLS is ever evaluated.

Trap 2 - you are about to "fix" it by opening the whole database.

The first search hit for permission denied for table supabase is the barrel-load answer:

grant all on all tables in schema public to anon, authenticated;

It works. Your table appears in the API immediately. It also hands anonymous visitors select, insert, update, and delete on every table in the database - including and especially the ones you never meant to expose. On a project where RLS is off on even one table, this command is a full database exposure, and it is the exact CVE-2025-48757 class of leak (170 production apps, 303 endpoints, public anon key).

The leak that was already there

While you are thinking about October 30, this is the query that finds your current problem:

select n.nspname as schema,
       c.relname as table,
       c.relrowsecurity as rls_enabled,
       coalesce(string_agg(
         g.grantee || ':' || g.privilege_type, ', '
         order by g.grantee), '(none)') as grants
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join information_schema.role_table_grants g
  on g.table_schema = n.nspname
 and g.table_name = c.relname
 and g.grantee in ('anon', 'authenticated')
where n.nspname = 'public'
  and c.relkind in ('r','p')
group by 1,2,3
order by c.relrowsecurity, c.relname;

rls_enabled = false with any anon:... grant = every profile in your database returns to a stranger with curl and your anon key. That key ships in your JavaScript bundle.
rls_enabled = false with anon:UPDATE on top = the same stranger can also rewrite rows.
The row that hurts looks like profiles | false | anon:SELECT, anon:UPDATE.

And the anon key check, one curl:

curl -s "https://YOUR_PROJECT.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: YOUR_ANON_KEY" | head -20

[] = RLS is doing its job.
rows = anonymous visitors can read this table.
42501 = the grant did not apply.

What to ship so both traps are impossible

Make grants part of the migration file, next to the table, next to the policies.

create table invoices (
  id uuid primary key default gen_random_uuid(),
  customer_id uuid not null,
  amount_cents integer not null,
  created_at timestamptz default now()
);

grant select on public.invoices to anon;          -- only if genuinely public
grant select, insert, update, delete on public.invoices to authenticated;
grant select, insert, update, delete on public.invoices to service_role;

alter table invoices enable row level security;
create policy "users see own invoices" on invoices
  for select to authenticated using (customer_id = auth.uid());

Three rules:

Grant to authenticated, not anon.
Never grant ... to anon with RLS off.
Never grant all on all tables ... to anon as the fix.

The honest version of the deadline

October 30 does not turn your RLS off. It does not touch existing tables. What it does is stop silently exposing the tables you create from now on - while leaving all the tables you already created exactly as open or closed as they were. The two jobs are separate: grant hygiene going forward, and an audit of what is already reachable today.

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

Free PDF checklist: https://cengokurtoglu.gumroad.com/l/nextjs-supabase-10-checks-free

What to do next (Complete 10-Product CTA Ladder)

Need	Product	Price	Time
Quick self-check	7-Surface Supabase Checklist (PDF)	Free	2 min
Self-serve audit	RLS Audit Kit	$29	30 min
Cut bill 50%	Supabase Cost Optimization Report	$99	24h
Multi-tenant bug	Multi-tenant RLS Policy Fix	$199	24h
File upload holes	File Upload Security	$199	24h
Stripe webhook broken?	Lovable Stripe Webhook Rescue	$399	24-48h
Auth breaks on domain	Auth Production Deploy Package	$499	24h
Edge functions wide open	Edge Function Security Hardening	$299	24h
Deploy with confidence	Supabase Migration Review	$299	24h
All-in-one launch	Launch-Ready SaaS Backend Bundle	$599	48h
Admin panel missing	Admin Panel Scaffold	$399	24h
Ongoing monitoring	Guard $50/mo	$50/mo	Recurring

Run the audit query above before October 30. The date is the excuse; the leak was the actual news.

Supabase RLS returns rows it shouldn't (or throws 42501): the 6 real causes

Cenk KURTOĞLU — Wed, 02 Sep 2026 23:41:43 +0000

If your Supabase app either shows data it shouldn't or blocks users with
42501 - new row violates row-level security policy, it's almost always one of
six causes. Work down the list; each has a 10-second check.

1. RLS was never enabled (the AI-tool trap)

Supabase enables RLS automatically only for tables created in the Table
Editor. Tables created via SQL editor, migrations, Prisma, or an AI coding
agent ship wide open.

select relname, relrowsecurity
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where nspname = 'public' and relkind = 'r' and not relrowsecurity;

Every row of that result is reachable by anyone holding your public anon key.

2. RLS enabled, but no policy matches ? everything denied

Postgres defaults to deny. If your table suddenly returns empty arrays after
you "turned security on", this is why: relrowsecurity = true with zero
applicable policies denies all rows to all roles.

3. The `USING (true)` policy that looks like security

create policy "allow_read" on public.profiles for select using (true);

This satisfies "we have RLS" while exposing every row. Search your policies:

select tablename, policyname from pg_policies
where schemame='public' and (qual = '(true)' or with_check = '(true)');

Each hit needs a human decision: is this table meant to be public?

4. Missing WITH CHECK on writes

A SELECT-only mindset leaks into INSERT/UPDATE policies without a WITH CHECK clause - and Postgres then derives an implicit check from USING,
which fails in confusing ways (especially on UPDATEs that rewrite the whole
row). Always write both halves explicitly:

create policy "users update own rows"
on public.items for update to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);

5. Dependent-policy lockout ("my admin policy is perfect but the table is empty")

Policies that subquery another table (exists (select 1 from profiles where ...))
fail silently when the inner table's own RLS hides its rows from the calling
user. Your admin sees nothing; a bare true policy "fixes" it - which is how
teams get talked into cause #3. Give the inner table a proper read-own-row
policy first.

6. Views, SECURITY DEFINER functions, and Storage

Post-15 views run as their owner by default ? can expose rows the table policies hide. Use security_invoker = true views.
security definer functions bypass RLS unless they set it themselves; pin set search_path.
Storage buckets have their own storage.objects policies - a private DB behind a public bucket is still public.

Prove your whole schema in 60 seconds: I put nine read-only queries that
cover causes 1-6 into a free SQL file you run in your own SQL editor - nothing
leaves your database:
github.com/cekuu35/supabase-rls-leak-demo ? audit/rls-audit.sql

The same repo contains a red/green test suite demonstrating the leak and the
one-file fix. If you want the full guided workflow (write-side checks,
role-simulation harness, remediation templates), that's the
Supabase RLS Audit Kit

$29, runs entirely against your own catalogs.

Disclosure: both links are mine. The audit queries and demo are free and MIT.

The service_role Key Hiding in Your .mcp.json — the AI-Vibe-Coder Secret Leak

Cenk KURTOĞLU — Sat, 15 Aug 2026 09:45:24 +0000

A year ago, the classic Supabase leak was a .env file committed to a public repo. Everyone learned to gitignore .env. Scanners learned to flag it. We mostly moved on.

But the way people build changed. Now you wire Supabase into Cursor, Claude Code, Windsurf, or VS Code through an MCP server, paste a key into a JSON config so your AI assistant can talk to your database, and keep shipping. That config file feels like an editor setting, not a secret. So it gets committed. And it's carrying the one credential that makes Row Level Security irrelevant.

This post is about that new leak surface — where it hides, why it's worse than a .env slip, and the exact order you fix it in. (Order matters more than you'd think.)

First, get the two keys straight

Supabase gives you two classes of API key, and the whole security story hinges on telling them apart.

Publishable / anon keys (sb_publishable_..., or the legacy anon JWT) are public by design. They are meant to ship in your browser bundle. Anyone can read them out of your JavaScript, and that is fine — because every request they make is still filtered through Row Level Security. The key identifies your project; RLS decides what that request is allowed to see. A publishable key with good RLS behind it is not a leak. It's the front door, and the front door is supposed to be visible.

Secret / service_role keys (sb_secret_..., or the legacy service_role JWT) are the opposite. Straight from the Supabase docs, they provide full access to your project's data, bypassing Row Level Security entirely. This key is a backend-only credential — for servers, Edge Functions, admin panels. It does not care what policies you wrote. It reads every row in every table, writes anything, deletes anything.

So here's the painful irony: developers panic when they realize their anon key is visible in the browser (it's fine), while the key that actually ends up in public places is the service_role key. And the newest place it ends up is your AI tooling config.

Where it actually hides now

When you connect Supabase to an AI coding assistant, the credential goes into a JSON file that lives inside your repo:

.mcp.json (Claude Code, project root)
.cursor/mcp.json (Cursor)
.vscode/mcp.json (VS Code)
~/.codeium/windsurf/mcp_config.json (Windsurf)
any mcp.json / mcp-config.json a tutorial told you to create

A typical entry looks like this:

{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": ["-y", "@supabase/mcp-server-supabase"],
      "env": {
        "SUPABASE_ACCESS_TOKEN": "sbp_0a1b2c3d...",
        "SUPABASE_SERVICE_ROLE_KEY": "sb_secret_9f8e7d..."
      }
    }
  }
}

There are actually three different disasters that show up in these files:

sb_secret_... / service_role — bypasses RLS, full data access.
A Supabase personal access token (sbp_...) — controls your whole account through the Management API: it can list projects, run SQL, even create or pause projects. This is arguably worse than a single project's service_role key.
A Postgres connection string — postgresql://postgres:PASSWORD@db.ref.supabase.co:5432/postgres. That's your database password in plaintext, i.e. direct superuser access to the box.

All three routinely land in MCP config because that's exactly what the quickstarts tell you to paste in.

Why this is worse than the old `.env` mistake

Three reasons.

It doesn't look like a secret. .env screams "credentials." .cursor/mcp.json reads like "my editor preferences." People commit editor config without a second thought — and often want to commit it so teammates get the same setup.

The tooling gap. Plenty of repos have .env in .gitignore and nothing else. .mcp.json, .cursor/, and .vscode/ are frequently tracked on purpose. Your existing ignore rules do not cover them.

It's already in your git history. This is the part people miss. Even if you delete the key from the current file and commit the fix, the secret still sits in a past commit. git log, any fork, any clone, GitHub's cached views, and every secret-scanning bot that already crawled your repo still have it. Deleting a secret from the latest commit does not un-leak it.

Check yourself in 30 seconds

From your repo root:

# Is a secret sitting in your history right now?
git log -p -S 'sb_secret_' -- . | head
git log -p -S 'service_role' -- . | head
git log -p -S 'sbp_' -- . | head

# Are the AI config files even tracked?
git ls-files | grep -E '(^|/)(\.mcp\.json|\.cursor/|\.vscode/mcp\.json)'

For a real audit, run a proper scanner over the whole history — gitleaks detect or trufflehog git file://. will find these across every commit, not just HEAD.

Fix it in the right order

If you found something, do these steps in this order. The order is the whole point.

1. Rotate first — before anything else. In the Supabase dashboard: for API keys, revoke the exposed secret key and create a new one; for a personal access token, revoke it under Account → Access Tokens; for a leaked DB password, reset it under Project Settings → Database. Rotation is what actually protects you, because it invalidates the leaked credential everywhere at once. Cleaning git history without rotating is theater — the secret was already public.

2. Then purge it from history. Now that the key is dead, scrub the value so bots stop flagging your repo: git filter-repo --replace-text or the BFG Repo-Cleaner, then force-push. (Coordinate with collaborators — this rewrites history.)

3. Stop it happening again. Add the config paths to .gitignore:

.mcp.json
.cursor/
.vscode/mcp.json
.env*

Commit a .mcp.json.example with ${SUPABASE_ACCESS_TOKEN} placeholders instead of real values, and keep the real ones in your shell environment or a secrets manager.

4. Reduce the blast radius. The Supabase MCP server supports --read-only and --project-ref flags. Scope the token to a single project and read-only access so that even a future leak can't write or delete. Give your AI assistant the least privilege that still lets it help.

The takeaway

The anon key in your browser was never the problem. The service_role key in your .cursor/mcp.json is. RLS is a genuinely strong wall — but service_role walks straight through it, and AI tooling has quietly created a brand-new way to commit that key to a public repo without realizing it.

So: audit your history, rotate anything you find, then clean up. In that order.

If you want to actually see this happen end to end, I put together a small reproducible demo — a repo with a service_role key wired into an MCP config, and a walkthrough of exactly what an attacker can pull once RLS is out of the picture and how the rotate-then-purge fix plays out: github.com/cekuu35/supabase-rls-leak-demo. It's free, no signup.

And if you'd rather run a full pass over your own project — RLS policies, key placement, and config-file leaks like the one above — I keep a paid Supabase RLS Audit Kit ($29) with the checklist and test scripts I use. Totally optional; the demo repo above already covers the leak in this post.

The Supabase Security Checklist to Run Before You Launch

Cenk KURTOĞLU — Sat, 15 Aug 2026 00:41:57 +0000

If you built something on Supabase with a lot of AI help and you're about to ship it, this checklist is for you. Supabase is secure by default in the sense that the tools are all there — but "vibe coding" tends to skip the boring parts, and the boring parts are exactly where data leaks live. Every item below is a one-line check plus the fix. Run them in order. It's maybe 30 minutes, and it's the difference between a launch and an incident.

1. RLS is enabled on every table in the `public` schema

The single most common Supabase mistake: a table exists, the anon key can reach it over PostgREST, and Row Level Security was never turned on. With RLS off, the table's GRANTs are the only gate — and because Supabase exposes the public schema to the anon role by default, that means anyone holding your (public) anon key can read it.

Check — run this in the SQL editor to list every public table with RLS off:

select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false;

Any rows returned are exposed. Fix each one:

alter table public.your_table enable row level security;

Enabling RLS with no policies is deny-all — a safe default. Now add the policy you actually want.

2. Every table has owner-scoped policies (not `using (true)`)

Enabling RLS isn't enough if your policy waves everyone through. The classic leak is using (true) with no to clause. A SELECT policy like that is world-readable, anon included. Two facts to keep straight: a policy with no TO clause applies to all roles, and for anon, auth.uid() is NULL — so any check that compares against it silently fails open or closed depending on how you wrote it.

Check — list every policy and read it:

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public';

qual is the USING expression; with_check is the WITH CHECK expression. A bare true in qual on a SELECT policy is world-readable. (It's only world-writable if a permissive INSERT/UPDATE/ALL policy also allows it — reads and writes are separate policies.) Fix with owner scoping:

-- users can only read their own rows
create policy "own rows are selectable"
on public.todos for select
to authenticated
using ( (select auth.uid()) = user_id );

-- and only insert rows they own
create policy "insert own rows"
on public.todos for insert
to authenticated
with check ( (select auth.uid()) = user_id );

Two things people get wrong here:

USING vs WITH CHECK. USING filters which existing rows a role can see, and which it may update or delete. WITH CHECK validates rows being written. An INSERT policy has WITH CHECK only — there are no existing rows to filter. UPDATE uses both. If you protect reads but forget WITH CHECK on writes, users can insert or update rows they shouldn't own.
A policy and a grant. A role needs a matching policy and the table GRANT. Multiple permissive policies OR together; restrictive policies AND. If access feels "too open," look for a second permissive policy widening things.

3. You're using the right key in the right place

Every Supabase project has two keys, and confusing them is catastrophic.

anon / publishable (role: anon, new format sb_publishable_...) is public by design. It's meant to ship in your browser bundle. It is not a secret, and it does not need rotating. RLS is what protects your data when this key is used.
service_role (role: service_role, new format sb_secret_...) is a server-only secret that bypasses RLS entirely — full read/write/delete across every table, plus Storage. It must never appear in a browser, a public repo, or a client config file.

Not sure which is which? Decode the JWT payload — the middle segment, base64URL — and read the role:

# paste your key; this prints the payload
echo 'PASTE_KEY' | cut -d. -f2 | base64 -d 2>/dev/null; echo

"role":"anon" is the browser key. "role":"service_role" must never leave your server.

The trap in frontend frameworks: any env var prefixed NEXT_PUBLIC_, VITE_, or EXPO_PUBLIC_ is inlined into the client bundle at build time. That's correct and safe for the anon key and project URL. Putting the service_role key behind one of those prefixes ships your master key to every visitor. Check your env files:

grep -rE 'NEXT_PUBLIC_|VITE_|EXPO_PUBLIC_' .env* | grep -i 'service\|secret'

Anything returned is a bug. The service_role key belongs only in server-side env — API routes, edge functions, backend — never behind a public prefix.

4. No secrets in the repo — or in git history

Deleting a secret file doesn't help if you already committed it once. A committed secret lives in git history forever. AI tooling makes this worse by scattering config files people don't think to check.

Check the working tree, including the easy-to-miss ones:

grep -rnE 'service_role|sb_secret_|eyJ[A-Za-z0-9_-]{20,}' \
  . --include='*.json' --include='*.env*' --include='*.ts' 2>/dev/null

# the ones vibe-coders forget:
git ls-files | grep -E '\.env|\.claude/settings\.local\.json|\.cursor/mcp\.json'

.claude/settings.local.json, .cursor/mcp.json, and .env.local love to hold live keys and DB connection strings. Then check history:

git log --all --full-history -p -- '.env*' '**/mcp.json' '.claude/settings.local.json'

Fix, in this order:

Rotate first. If a service_role key (or DB password) was ever committed, treat it as compromised. Regenerate it in the dashboard under Project Settings -> API. Deleting the file does not un-leak it.
Purge history with git filter-repo (or BFG), then force-push:

git filter-repo --path .env.local --invert-paths

Add the patterns to .gitignore so it can't recur:

.env*
.claude/settings.local.json
.cursor/mcp.json

Order matters: rotate before you spend time rewriting history, because the old key is public the moment the repo is.

5. Storage buckets have real policies

Storage is Postgres too — access lives in storage.objects and obeys RLS. A public bucket means the files are readable by URL to anyone. A private bucket with no policy means no one can read it, which is usually not what you shipped either.

Check your buckets and their object policies:

select id, name, public from storage.buckets;

select policyname, cmd, roles, qual
from pg_policies
where schemaname = 'storage' and tablename = 'objects';

Decide per bucket: are these files meant to be world-readable (avatars, marketing images) or private (invoices, uploads)? For an owner-scoped private bucket, a common pattern keys access to a per-user folder:

create policy "users read own folder"
on storage.objects for select
to authenticated
using (
  bucket_id = 'user-uploads'
  and (select auth.uid())::text = (storage.foldername(name))[1]
);

6. Do a real self-audit before you trust the checklist

Reading policies by hand is exactly where over-confidence creeps in — a policy can look scoped and still leak because of a second permissive policy or a missing TO. So verify empirically.

I keep a small free repo for this: github.com/cekuu35/supabase-rls-leak-demo. It's a minimal reproduction of the classic RLS leak plus read-only audit SQL you can paste into your own SQL editor to list tables without RLS, policies with no TO clause, and using (true) permissive policies in one shot. It changes nothing in your database — it just tells you where you stand.

The most honest test, though, is to hit your project the way an attacker would: with nothing but the public anon key.

curl "https://<project-ref>.supabase.co/rest/v1/your_table?select=*" \
  -H "apikey: <ANON_KEY>"

If that returns rows you expected to be private, RLS is not doing what you think. Fix it before launch, not after.

Run all six and you've closed the failure modes behind almost every "Supabase leaked my data" post-mortem: RLS off, using (true), the wrong key in the bundle, and a secret buried in git history.

If you'd rather not assemble this by hand, I packaged the whole thing — the audit queries, owner-scoped policy templates for the common table shapes, the Storage patterns, and a printable pre-launch checklist — into a $29 RLS Audit Kit. The free demo repo above is genuinely enough to secure your project; the kit just saves you the afternoon of writing the SQL yourself. Either way, ship it locked down.

NEXT_PUBLIC_ and Supabase: Which Env Variables Are Safe to Expose?

Cenk KURTOĞLU — Sat, 15 Aug 2026 00:37:50 +0000

If you've ever stared at a .env.local full of Supabase keys and wondered "wait, which of these is safe to ship to the browser?" — you're not alone. It's one of the most common questions I see, and getting it wrong ranges from "totally fine" to "someone just dumped your entire users table." Let's clear it up for good.

The one rule that explains everything

In Next.js, any environment variable prefixed with NEXT_PUBLIC_ gets inlined into the JavaScript bundle at build time. Same story for VITE_ in Vite apps and EXPO_PUBLIC_ in Expo. The prefix is not a suggestion — it's an instruction to the bundler: copy this value into code that runs in the user's browser.

So the question "is this variable safe to expose?" is really "is it safe for this value to sit in plain text inside the client bundle, readable by anyone who opens DevTools?"

For Supabase, the answer depends entirely on which key you're talking about.

Every Supabase project has two keys, and they are not equals

Open your project's API settings and you get two keys. They look similar. They could not be more different.

1. The anon key (newer projects call this the publishable key, formatted sb_publishable_...). Its JWT carries "role": "anon". This key is public by design. It's meant to ship in the browser. It is not a secret, and you do not need to rotate it if it "leaks" — because it was never hidden in the first place. What keeps your data safe when this key is used is Row Level Security (RLS): the anon key can only do what your RLS policies allow.

2. The service_role key (formatted sb_secret_... on newer projects). Its JWT carries "role": "service_role". This key bypasses Row Level Security entirely. Full read, write, and delete on every table, plus Storage. It exists for trusted server environments only. It must never appear in a browser bundle, a public repo, or any client-side config.

Here's a reliable way to tell any Supabase JWT apart — decode the middle segment (it's base64url) and read the role:

# paste your key in place of $KEY
echo "$KEY" | cut -d. -f2 | tr '_-' '/+' | base64 -d 2>/dev/null | grep -o '"role":"[a-z_]*"'
# => "role":"anon"          -> public, safe for the browser
# => "role":"service_role"  -> secret, server-only, never public

(The tr '_-' '/+' converts base64url to standard base64 so base64 -d can read it.) The newer sb_publishable_ / sb_secret_ keys aren't JWTs, but the naming makes the distinction obvious — secret means secret.

So, the safe list

Safe to expose (belongs in NEXT_PUBLIC_):

NEXT_PUBLIC_SUPABASE_URL=https://xxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=sb_publishable_xxx   # or the legacy anon JWT

The project URL is public — it's just an HTTPS endpoint. The anon key is public by design. Ship them.

Never public (no NEXT_PUBLIC_ prefix, ever):

SUPABASE_SERVICE_ROLE_KEY=sb_secret_xxx
DATABASE_URL=postgresql://postgres:password@db.xxxx.supabase.co:5432/postgres

DATABASE_URL contains your database password and gives direct Postgres access. That connection bypasses RLS the same way service_role does — the postgres role is not subject to your policies. Both stay strictly server-side.

Keeping service_role strictly server-side

The safe pattern: the browser talks to Supabase with the anon key (protected by RLS), and anything that genuinely needs to bypass RLS runs on a server you control. Next.js gives you three good homes for that.

Route handlers (app/api/.../route.ts):

// app/api/admin-report/route.ts
import { createClient } from '@supabase/supabase-js'

// No NEXT_PUBLIC_ prefix -> stays on the server, never bundled
const admin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

export async function GET() {
  // runs server-side only; safe to use the service_role client here
  const { data, error } = await admin.from('reports').select('*')
  if (error) return Response.json({ error: error.message }, { status: 500 })
  return Response.json(data)
}

Server Actions work the same way — they only ever execute on the server, so reading process.env.SUPABASE_SERVICE_ROLE_KEY there is fine:

'use server'
import { createClient } from '@supabase/supabase-js'

export async function deleteAccount(userId: string) {
  const admin = createClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!
  )
  await admin.from('profiles').delete().eq('id', userId)
}

Supabase Edge Functions get the service_role key from their own secret store (Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')), completely outside your frontend build — a great home for privileged jobs.

The mental model: if a file has 'use client' at the top, or gets imported by one, assume everything in it is public. Never read a secret there.

Catch the mistake before it ships

The classic disaster is one character of muscle memory: someone types NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY because every other Supabase var starts that way. Now your RLS-bypassing key is inlined into the client bundle.

Grep for it. Add this to CI or a pre-commit hook:

# Fails if any NEXT_PUBLIC_ / VITE_ / EXPO_PUBLIC_ var references service_role
git grep -nE '(NEXT_PUBLIC_|VITE_|EXPO_PUBLIC_)[A-Z_]*SERVICE_ROLE' && {
  echo "FATAL: service_role key exposed via a public env prefix"; exit 1
} || echo "OK: no service_role key behind a public prefix"

It's also worth scanning the built output itself — a secret can leak through a hardcoded string even without the prefix:

# after `next build`
grep -rE 'sb_secret_|service_role' .next/static && \
  echo "FATAL: secret found in client bundle" || echo "clean"

If a secret already leaked

Two things, in order. First, rotate the key in your Supabase dashboard immediately — a leaked service_role key is a live master key until you do. Second, remember that deleting the file in a new commit is not enough: the value lives in your git history forever, and anyone can git log -p it back. You have to purge history with git filter-repo (or the BFG), then force-push:

git filter-repo --path .env.local --invert-paths

Rotate and purge. One without the other leaves you exposed.

The part people forget: the anon key is only as safe as your RLS

Shipping the anon key is safe only because RLS stands between it and your data. If a table has RLS disabled, or has a policy like USING (true) with no TO clause, then that "public" anon key can read every row — for every user. A SELECT policy of USING (true) is genuinely world-readable. (It's only world-writable if a permissive INSERT/UPDATE/ALL policy exists too — but world-readable is already a breach for most apps.)

Remember the anatomy:

USING filters which existing rows a role can see, and which it may update or delete.
WITH CHECK validates rows being inserted or updated; INSERT policies have WITH CHECK only.
A role needs both a matching policy and the underlying table GRANT. Permissive policies OR together; restrictive ones AND.
A policy with no TO clause applies to all roles, anon included.
For an anonymous visitor, auth.uid() is NULL — so any policy that quietly assumes a logged-in user needs testing from the anon perspective.

If you want to actually check your own project rather than take my word for it, I put together a free, read-only audit: github.com/cekuu35/supabase-rls-leak-demo. It's a tiny reproducible leak plus a set of SQL queries you can paste into the Supabase SQL editor to list every table with RLS off and every policy that resolves to true for anon. Run it against a staging project and see what falls out — it's usually one or two tables you forgot about.

The takeaway

NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY: public by design, ship them.
SUPABASE_SERVICE_ROLE_KEY and DATABASE_URL: server-only, no public prefix, ever.
Decode the JWT role when you're unsure; git grep for the prefix mistake in CI.
The anon key's safety is your RLS — so audit your policies, don't assume them.

If you'd rather not hand-roll the whole audit, I also maintain a $29 RLS Audit Kit — the same read-only checks packaged with a policy checklist and a few "here's the fix" templates for the leaks it turns up. Totally optional; the free demo above will already get you most of the way. Either way, go check your policies today — future-you will be glad you did.

You Committed .env to GitHub: What to Rotate (Supabase + Next.js)

Cenk KURTOĞLU — Sat, 15 Aug 2026 00:33:34 +0000

You pushed, then your stomach dropped: .env is in the commit. Maybe a bot already emailed you. Take a breath — this is recoverable, and panicking into random git commands usually makes it worse.

The single most important thing to understand: deleting the file does not fix anything. Once a secret is in git history, assume it is public forever. The real fix is rotation — making the leaked value useless by replacing it upstream. Purging history is cleanup you do after rotating, not instead of it.

Let's go value by value through a typical Supabase + Next.js .env, sort out what's actually a secret, and rotate only what matters.

First: which of these is actually secret?

A typical .env looks like this:

NEXT_PUBLIC_SUPABASE_URL=https://abcdxyz.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOi...        # role: anon
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOi...            # role: service_role
SUPABASE_JWT_SECRET=super-secret-signing-key
DATABASE_URL=postgresql://postgres:PASSWORD@db.abcdxyz.supabase.co:5432/postgres
STRIPE_SECRET_KEY=sk_live_...
RESEND_API_KEY=re_...

Here's the part that saves you hours of unnecessary panic.

Safe by design — do NOT need rotating:

NEXT_PUBLIC_SUPABASE_URL — your project URL is public. It's in every network request the browser makes.
NEXT_PUBLIC_SUPABASE_ANON_KEY — the anon (publishable) key is public by design. It ships in your client bundle on purpose. Any NEXT_PUBLIC_ variable is inlined into the browser JavaScript at build time, so it was never a secret to begin with.

The anon key's role is anon. It has no special power on its own — it's just an identity meaning "an unauthenticated (or logged-in) user of this project." What protects your data when that key is used is Row Level Security (RLS). If your tables have RLS enabled with correct policies, a leaked anon key is a non-event. If they don't, that key was already exposed to every visitor of your site — the git commit changed nothing.

Actually secret — rotate every one of these:

SUPABASE_SERVICE_ROLE_KEY
SUPABASE_JWT_SECRET
DATABASE_URL (the Postgres password inside it)
Every third-party key: Stripe, Resend, OpenAI, etc.

The service_role key is the scary one. Its role is service_role, and it bypasses RLS entirely — full read, write, and delete on every table, plus Storage. It's a server-only secret. It must never appear in a browser, a public repo, or anything with a NEXT_PUBLIC_ prefix. If it leaked, treat it as a full database breach until rotated.

How to tell the two keys apart

Both are JWTs, so they look identical at a glance. Decode the middle segment (base64URL) and read the role claim:

# paste your key in place of PASTE_KEY
echo 'PASTE_KEY' | cut -d. -f2 | base64 -d 2>/dev/null | python -m json.tool

You'll see either "role": "anon" (safe, public) or "role": "service_role" (secret, rotate now). Newer Supabase projects use clearer prefixes instead of JWTs: sb_publishable_... (public) vs sb_secret_... (secret). The prefix tells you everything — no decoding needed.

Rotating each secret

The Supabase keys

In the dashboard, go to Project Settings -> API Keys. How rotation works depends on which key system your project uses:

New keys (sb_publishable_ / sb_secret_): these are independent of each other and of the JWT secret. Revoke the leaked sb_secret_ key and create a new one; the publishable key is unaffected because it wasn't a secret.
Legacy JWT keys: both the anon and service_role keys are JWTs signed by your project's JWT secret. Rolling that secret regenerates both keys at once, because both are signatures over it.

Either way, after rotating the secret:

Copy the new service_role / sb_secret_ key into your server environment (Vercel project env vars, .env.local, etc.).
If you rolled a legacy JWT secret, also grab the regenerated anon key and redeploy so the fresh key ships in your bundle.

One consequence to expect on the legacy path: rolling the JWT secret invalidates every JWT signed with the old one, which logs out all existing user sessions. That's the correct, safe outcome after a leak — do it anyway.

Database password

Project Settings -> Database -> Reset database password. This changes the password embedded in your DATABASE_URL / connection string. Update that string everywhere it lives (Vercel, CI secrets, local .env.local, migration tooling). Anything still using the old password starts failing — that's your checklist of places to fix.

Third-party keys

Each provider has its own flow, but the pattern is identical: generate a new key, deploy it, then revoke the old one. Don't skip the revoke — a new key does not disable the leaked one.

Stripe: Developers -> API keys -> roll the leaked secret key.
Resend / OpenAI / etc.: create new key, swap in env, delete old.

Now purge git history

Rotation makes the leaked values worthless. Purging history is about hygiene and not re-leaking on the next clone. Deleting the file in a new commit is not enough — the old commit still contains it.

The clean tool is git filter-repo:

pip install git-filter-repo

# remove the file from all of history
git filter-repo --path .env --invert-paths

Or with BFG:

bfg --delete-files .env
git reflog expire --expire=now --all && git gc --prune=now --aggressive

Then force-push the rewritten history:

git push origin --force --all
git push origin --force --tags

Two honest caveats: force-pushing rewrites history for every collaborator (they'll need to re-clone or reset), and GitHub caches commits — forks and cached commit views can retain the blob even after your push. That's exactly why rotation is the real fix and history-purging is secondary. Then add .env to .gitignore so this can't recur:

echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
git rm --cached .env      # stop tracking without deleting your local copy

The part everyone skips: is your RLS actually protecting you?

Here's the uncomfortable truth. If a leaked anon key genuinely exposes your data, the anon key wasn't the vulnerability — your RLS was. That key is public to every visitor regardless of any git leak.

A few things worth checking on every table:

RLS is enabled on the table. Enabling it with no policies denies all access through the API — that's fail-safe, not broken.
A role needs both a matching policy and the underlying table GRANT.
A policy with no TO clause applies to every role, including anon.
USING (true) on a SELECT policy makes the table world-readable. It's only world-writable if a permissive INSERT/UPDATE/ALL policy also exists (INSERT policies gate rows with WITH CHECK, not USING).
For an anonymous request, auth.uid() is NULL — so USING (auth.uid() = user_id) correctly returns nothing to anon.

Quick audit of what's exposed:

-- tables with RLS OFF (guarded only by GRANTs, no policy gate)
select relname
from pg_class
where relkind = 'r'
  and relnamespace = 'public'::regnamespace
  and not relrowsecurity;

-- every policy, so you can eyeball no-TO and USING(true)
select schemaname, tablename, policyname, roles, cmd, qual, with_check
from pg_policies
where schemaname = 'public'
order by tablename;

If reading those results makes you nervous, I put together a free, read-only repro and audit kit here: github.com/cekuu35/supabase-rls-leak-demo. It has a deliberately leaky schema plus copy-paste SQL that flags world-readable tables and no-TO policies, so you can see exactly what an anon key can reach in your own project.

The 60-second recap

Don't panic, don't just delete the file.
Anon key + project URL + NEXT_PUBLIC_ vars: safe, no rotation needed.
service_role, JWT secret, DB password, third-party keys: rotate now, revoke the old ones.
Purge history with filter-repo/BFG and force-push — but only after rotating.
Audit your RLS, because that's what actually stands between the public anon key and your data.

If you want to go deeper than the free audit — a full policy-by-policy checklist, the common false-positive traps, and fix templates — I keep a $29 RLS Audit Kit that packages it all up. Totally optional; the free demo repo above is enough to check and fix most projects on your own. Either way: rotate first, breathe second, and get RLS right so the next leak is a shrug instead of a scramble.

Test Your Supabase RLS Policies Locally: A Free SQL Harness

Cenk KURTOĞLU — Sat, 15 Aug 2026 00:30:34 +0000

Row Level Security is the thing standing between your Supabase tables and the whole internet. Your anon key ships in the browser bundle on purpose — that's fine, that's by design, it isn't a secret — but it means any row your policies fail to lock down is a row a stranger can read with curl. So the real question isn't "do I have RLS on?" It's "do my policies actually do what I think they do?"

The good news: you can answer that in a local Postgres, deterministically, without touching production or hitting a rate limit. The trick is that Supabase's auth.uid() and the anon / authenticated roles are just Postgres primitives you can reproduce. This is a walkthrough of a small harness that impersonates anon and any logged-in user right in psql.

Everything here is packaged as a ready-to-run repo: github.com/cekuu35/supabase-rls-leak-demo. Clone it if you'd rather run than copy-paste.

How Supabase auth maps to plain Postgres

Two facts unlock the whole thing:

When PostgREST handles a request, it does SET ROLE anon (or authenticated) and stuffs the decoded JWT into a session setting called request.jwt.claims.
auth.uid() is just a SQL function that reads sub out of those claims.

The service_role key is different in kind — it's a server secret that bypasses RLS entirely (full read, write, delete, plus Storage). It never belongs in a browser, a public repo, or a client config, and it's not what we're testing here. (Reflex check: a NEXT_PUBLIC_ / VITE_ / EXPO_PUBLIC_ prefix inlines a value straight into the client bundle — safe for the anon key and project URL, catastrophic for service_role. Tell the two keys apart by decoding the JWT's middle segment as base64URL: "role":"anon" vs "role":"service_role" — or by the newer sb_publishable_ vs sb_secret_ prefixes.) We're testing the role that is exposed: anon.

So to reproduce a request locally, we set the role and set the claims. That's it.

Step 1 — a minimal shim

If you run the full stack with supabase start, the auth schema and roles already exist and you can skip this. On a bare Postgres, create them:

-- roles PostgREST switches into
do $$
begin
  if not exists (select from pg_roles where rolname = 'anon') then
    create role anon nologin;
  end if;
  if not exists (select from pg_roles where rolname = 'authenticated') then
    create role authenticated nologin;
  end if;
end $$;

-- the same auth.uid() Supabase gives you
create schema if not exists auth;
create or replace function auth.uid() returns uuid
language sql stable
as $$
  select nullif(current_setting('request.jwt.claims', true)::jsonb ->> 'sub', '')::uuid
$$;

The true argument to current_setting means "return NULL instead of erroring if it's unset" — which is exactly the anonymous case. For anon, auth.uid() is NULL. Keep that in mind: any policy written as auth.uid() = user_id silently denies the anon user, because NULL = anything is never true. That's usually what you want.

Step 2 — a table with a policy to test

create table if not exists documents (
  id       bigint generated always as identity primary key,
  owner_id uuid not null,
  title    text not null,
  body     text
);

alter table documents enable row level security;

-- owners can read their own rows
create policy "owner can read"
  on documents for select
  to authenticated
  using (auth.uid() = owner_id);

Note the to authenticated. A policy with no TO clause applies to all roles, including anon — a common way to leak data by accident. Being explicit about the role is half the battle.

Step 3 — impersonate anon and a real user

Wrap each check in a transaction with SET LOCAL so the role and claims reset automatically on ROLLBACK. That keeps tests isolated and non-destructive.

-- as an anonymous visitor (no JWT)
begin;
  set local role anon;
  select count(*) as anon_sees from documents;
rollback;

-- as a specific logged-in user
begin;
  select set_config(
    'request.jwt.claims',
    json_build_object(
      'sub',  '11111111-1111-1111-1111-111111111111',
      'role', 'authenticated'
    )::text,
    true                       -- is_local: scoped to this transaction
  );
  set local role authenticated;
  select id, title from documents;      -- only their rows
rollback;

Set the claims before switching role, then switch. Now you can assert concrete numbers. With the policy above, anon_sees should be 0, and the authenticated block should return only rows whose owner_id matches that sub. If anon_sees is anything but zero, you have a leak — go look at your TO clauses and USING expressions.

The two mistakes worth internalizing

USING vs WITH CHECK are not interchangeable. USING decides which existing rows a role can see, and which it's allowed to scan for UPDATE / DELETE. WITH CHECK validates the new row values on INSERT / UPDATE. INSERT policies have WITH CHECK only. Getting these backwards is how people write an "owners only" update policy whose USING guards the old row but whose missing WITH CHECK lets anyone reassign a row to themselves.

USING (true) means world-readable for SELECT. A SELECT policy with USING (true) simply lets everyone read — genuinely fine for a public catalog. It only becomes a write hole if a permissive INSERT / UPDATE / ALL policy also opens that path. Permissive policies OR together, so one stray using(true) with no TO widens access to anon in whatever command it targets. And a role needs both a matching policy and the table GRANT: RLS with the grant missing fails closed, while a grant on a table with RLS still disabled fails wide open.

Step 4 — audit the whole schema at once

Before you write per-table tests, get a bird's-eye view. Two read-only queries surface most real problems.

Tables where RLS is off entirely:

select n.nspname as schema, c.relname as table
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind = 'r'
  and not c.relrowsecurity;

Every policy, with the fields that matter — roles, cmd, and the actual expressions:

select tablename,
       policyname,
       roles,          -- {public} = applies to anon too
       cmd,            -- SELECT / INSERT / UPDATE / DELETE / ALL
       qual       as using_expr,
       with_check as check_expr
from pg_policies
where schemaname = 'public'
order by tablename, cmd;

Read it like a reviewer: any row where roles is {public} and using_expr is true on a table with private data is a red flag. Any table in the first query's output that isn't meant to be fully public is a bigger one. The demo repo ships this audit SQL as a single file plus a seeded leak you can watch the harness catch — a fast way to confirm your setup works before you point it at your own schema.

Wire it into CI

Because the whole thing is SQL against a throwaway database, it runs anywhere Postgres does. A pg_prove file or even a plain script that fails when anon_sees > 0 will do:

psql "$DATABASE_URL" -v ON_ERROR_STOP=1 -f test/rls_anon_readonly.sql

Run it against supabase db reset output on every push. Now a policy regression breaks the build instead of leaking rows in production.

Where to go from here

You now have a repeatable way to prove — not hope — that anon sees exactly what you intend. Clone github.com/cekuu35/supabase-rls-leak-demo, run the audit against your schema, and fix whatever the pg_policies query lights up.

If you'd rather not hand-roll the assertions, I keep a small RLS Audit Kit ($29) — the same harness plus a checklist of per-command policy tests (insert-as-other-user, update-reassignment, delete-scope) and copy-paste pg_prove cases. Entirely optional; the repo above is enough to secure your project today. Either way, go run the anon check before you ship.

Supabase RLS with auth.uid() not working? Causes and fixes

Cenk KURTOĞLU — Sat, 15 Aug 2026 00:27:20 +0000

You wrote a tidy Row Level Security policy, something like auth.uid() = user_id, and now one of two annoying things happens: your query returns no rows at all, or it returns everybody's rows. Both are common, both are fixable, and neither means RLS is broken. It means the policy isn't seeing the identity you think it's seeing.

Let's walk the actual causes, in rough order of how often they bite people, with copy-pasteable SQL you can run against your own project.

First, what `auth.uid()` actually is

auth.uid() reads the sub claim out of the JWT attached to the current request. No JWT, or a JWT without a user, means auth.uid() returns NULL.

That single fact explains most "no rows" bugs. A policy like auth.uid() = user_id becomes NULL = user_id, which evaluates to NULL (not true), so the row is filtered out. Every row. Silently.

So the first debugging question is never "is my policy wrong?" It's "who does the database think I am right now?"

Cause 1: You're on the anon key, so auth.uid() is NULL

Every Supabase project ships two keys, and they are not interchangeable:

anon / publishable (role: anon) — public by design. It's meant to sit in your browser bundle. It is not a secret and does not need rotating. RLS is what protects your data when this key is used.
service_role (role: service_role) — a server-only secret that bypasses RLS entirely. More on why that's dangerous below.

If you initialize the client with the anon key and the user hasn't logged in, there's no user JWT, so auth.uid() is NULL and auth.uid() = user_id matches nothing.

Confirm which key you're holding by decoding the middle segment of the JWT (base64url-encoded JSON):

echo 'PASTE_KEY_HERE' | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool

Read the role field: "anon" or "service_role". The newer key formats make it obvious without decoding: sb_publishable_... is public, sb_secret_... is the secret one.

Then confirm you're actually authenticated. In the browser:

const { data: { user } } = await supabase.auth.getUser()
console.log(user)   // null here means auth.uid() will be NULL server-side

If user is null, fix sign-in first — no policy change helps until the request carries a user JWT.

Cause 2: RLS isn't actually enabled, so you get everything

The opposite symptom — you see all rows — usually means RLS isn't switched on for the table. Policies are ignored entirely until you enable RLS:

select relname, relrowsecurity
from pg_class
where relname = 'your_table';

If relrowsecurity is false, turn it on:

alter table your_table enable row level security;

One gotcha: the table owner and superusers still bypass RLS. To apply the rules even to the owner, add alter table your_table force row level security;.

Cause 3: You're testing with service_role, so it "works" (misleadingly)

The sneakiest one. Your test passes, data comes back exactly right — because the test client is using the service_role key, which bypasses RLS completely. You're not testing your policies; you're testing with the guard switched off.

service_role belongs only on a trusted server. Never in a browser, never in a public repo, never in a client .env that gets bundled. Anything prefixed NEXT_PUBLIC_, VITE_, or EXPO_PUBLIC_ gets inlined into the client bundle at build time — perfect for the anon key and project URL, catastrophic for service_role.

And if service_role has already been committed to a repo: deleting the file is not enough. A committed secret lives in git history forever. Rotate the key in the dashboard and purge history (git filter-repo or BFG). Rotation is the part that actually revokes the leak; history-scrubbing stops the old value from being fetched back out.

Test policies with the anon key plus a real logged-in session, the way your app runs. To check directly in SQL, impersonate a role and a user inside a transaction:

begin;
-- become the anon role
set local role anon;
select * from your_table;   -- honors your anon policies

-- now simulate a logged-in user
set local role authenticated;
select set_config(
  'request.jwt.claims',
  '{"sub":"11111111-1111-1111-1111-111111111111","role":"authenticated"}',
  true
);
select * from your_table;   -- auth.uid() now returns that sub
rollback;

If it returns rows here but not in your app, the difference is your app's auth state, not the policy.

Cause 4: Missing GRANT

RLS policies do not grant access — they restrict it. A role needs both a matching policy and a table-level privilege. If anon or authenticated was never granted SELECT, no policy will save you; the query errors out regardless of the rows.

select grantee, privilege_type
from information_schema.role_table_grants
where table_name = 'your_table';

Supabase's default setup grants the API roles broad privileges, but if you've been locking things down by hand you may have revoked them:

grant select, insert, update, delete on your_table to authenticated;

Then let RLS decide which rows each user actually touches.

Cause 5: Missing (or wrong) TO clause

A policy with no TO clause applies to every role, including anon. That's a frequent source of "why can logged-out visitors read this?"

Scope policies explicitly:

create policy "Users read own rows"
on your_table
for select
to authenticated                       -- <- this line matters
using ( (select auth.uid()) = user_id );

Multiple permissive policies are OR'd together, so a broad one you forgot about widens access. List what's really on the table:

select policyname, cmd, roles, qual, with_check
from pg_policies
where tablename = 'your_table';

Read the roles column. If you see {public} where you expected {authenticated}, that's your leak — public means every role, anon included.

Cause 6: Comparing a uuid to a text column

auth.uid() returns a uuid. If your user_id column is text, Postgres resolves uuid = text by casting the text to uuid — which throws invalid input syntax for type uuid the moment any value isn't a well-formed uuid, and adds a per-row cast even when it isn't. Check the type:

select column_name, data_type
from information_schema.columns
where table_name = 'your_table' and column_name = 'user_id';

The clean fix is a real uuid column referencing auth.users:

alter table your_table
  alter column user_id type uuid using user_id::uuid;

If you can't change the schema right now, cast inside the policy so both sides match:

using ( (select auth.uid())::text = user_id )

Prefer fixing the column type — a uuid that references auth.users(id) indexes better and is harder to get wrong later.

The policy pattern to standardize on

Notice I keep writing (select auth.uid()) instead of bare auth.uid(). Wrapping it in a select lets Postgres evaluate the function once per query instead of once per row — a real, measurable win on larger tables, and the pattern Supabase now recommends. A complete per-user set:

alter table documents enable row level security;

create policy "read own documents"
on documents for select
to authenticated
using ( (select auth.uid()) = user_id );

create policy "insert own documents"
on documents for insert
to authenticated
with check ( (select auth.uid()) = user_id );

create policy "update own documents"
on documents for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

Mental model for the two clauses: USING filters which existing rows a role can see (and which rows an UPDATE/DELETE may touch); WITH CHECK validates the new values being written. INSERT policies have WITH CHECK only. UPDATE usually wants both — USING to pick the row, WITH CHECK so a user can't reassign user_id to someone else.

A 60-second self-audit

-- tables in public with RLS still disabled
select c.relname
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind = 'r'
  and c.relrowsecurity = false;

-- policies with no role restriction (they apply to anon too)
select tablename, policyname, cmd, roles
from pg_policies
where schemaname = 'public'
  and roles = '{public}';

If you want a reproducible sandbox where each failure mode fires on demand — anon-key NULL, missing GRANT, service_role bypass — plus a fuller read-only audit query to paste into the SQL editor, I put a small demo repo together: github.com/cekuu35/supabase-rls-leak-demo. Clone it, run the SQL, and watch the "no rows / all rows" behavior flip as you toggle each cause. It's the fastest way I know to build the intuition.

The takeaway

When auth.uid() "doesn't work," it's almost never that RLS is broken. It's that the request isn't carrying the identity you assume: you're on the anon key with no session, RLS was never enabled, a test used service_role and hid the bug, a GRANT is missing, the TO clause is too wide, or a uuid is being compared to text. Walk the six checks in order and you'll find it.

If you'd rather not hand-audit every time you ship a new table, I maintain a $29 RLS Audit Kit — ready-to-run policy tests and a checklist that flags exactly these six failure modes across your whole schema. Entirely optional; the queries above will get you unstuck today either way.

Is my Supabase anon key exposed? What's actually safe (and what isn't)

Cenk KURTOĞLU — Sat, 15 Aug 2026 00:23:23 +0000

You pushed your app, opened DevTools, and there it is in plain sight: your Supabase key, sitting in the JavaScript bundle for the whole world to read. Your stomach drops. Did you just leak the keys to your database?

Take a breath. In the overwhelming majority of cases, the answer is: no, that key is public by design and you did nothing wrong. But there's a real version of this panic that is an emergency, and the difference between the two is worth understanding precisely. Let's sort it out calmly.

Every Supabase project has two keys

When you spin up a project, Supabase hands you two API keys, and they could not be more different:

anon / publishable key (role: anon) — the public one. It is meant to ship in your browser bundle, your mobile app, your public repo. It is not a secret. It does not need rotating just because someone saw it.
service_role key (role: service_role) — a server-only secret. It bypasses Row Level Security entirely — full read, write, and delete on every table, plus Storage. This one must never touch a browser, a public repo, or client config.

Newer projects use the sb_publishable_... and sb_secret_... formats, where the prefix alone tells you which is which. Older projects use JWTs that both start with eyJ... and look nearly identical at a glance — which is exactly why people panic.

So the first question isn't "is my key exposed?" It's "which key is exposed?"

Decode the key to find out which one you have

Both legacy keys are JWTs: three base64url segments separated by dots. The middle segment is the payload, and it names the role. You never need a library — just decode the middle part.

In the browser console:

const key = "eyJhbGciOi..."; // paste your key
JSON.parse(atob(key.split(".")[1]));
// { "role": "anon", "iss": "supabase", ... }  -> public, safe to ship
// { "role": "service_role", ... }             -> secret, get it out now

Or from a terminal:

echo "eyJhbGciOi..." | cut -d. -f2 | base64 -d 2>/dev/null

If you see "role":"anon" — relax. That key in your bundle is doing exactly what it's supposed to.

If you see "role":"service_role" — this is the real emergency. Skip to the last section.

Why is the anon key safe to make public?

Because the anon key isn't what protects your data. Row Level Security (RLS) is.

Think of the anon key as a library card that only says "this person is an anonymous visitor." It gets you through the front door of the API. What you can actually read or touch once inside is decided by RLS policies on each table. With RLS enabled and no policy granting access, the anon role sees nothing.

This is the mental-model shift that dissolves the panic: exposing the anon key is only a problem if your tables aren't protected by RLS. The key was never the wall. It's the doorbell.

The actual thing to check: is RLS on and scoped?

Here's where the genuine risk lives, and it has nothing to do with the key being visible. Run this in the Supabase SQL editor to find every table in public with RLS switched off:

select relname as table_name, relrowsecurity as rls_enabled
from pg_class
where relnamespace = 'public'::regnamespace
  and relkind = 'r'
order by relrowsecurity, relname;

Any row where rls_enabled is false is readable and writable by anyone holding your anon key — which, again, is everyone. That's the leak that matters.

Enabling RLS is one line per table:

alter table public.profiles enable row level security;

But RLS with no policies means nobody except service_role can read anything — so you then add policies that scope access. A quick model of how policies work, because the details trip people up:

USING filters which existing rows a role may see, and which it may UPDATE/DELETE.
WITH CHECK validates rows being inserted or updated. INSERT policies have WITH CHECK only.
A role needs both a matching policy and the table GRANT. Permissive policies OR together; restrictive ones AND.
A policy with no TO clause applies to every role, including anon. Classic footgun.
For the anon role, auth.uid() is NULL — so auth.uid() = user_id naturally matches nothing for anonymous callers.

A typical "users only see their own rows" policy:

create policy "own rows are visible"
on public.profiles
for select
to authenticated
using ( auth.uid() = user_id );

Now audit what you actually have. This lists every policy and its expressions so you can eyeball the dangerous ones:

select tablename, policyname, cmd, roles, qual as using_expr, with_check
from pg_policies
where schemaname = 'public'
order by tablename, cmd;

Two patterns to hunt for:

using (true) on a SELECT policy that reaches anon = world-readable table. Sometimes intentional (a public blog); often not.
using (true) on an INSERT, UPDATE, or ALL policy = world-writable. That's how strangers end up inserting rows into your database.

If reading raw pg_policies output makes your eyes cross, I put together a small public repo that reproduces the exact leaky-vs-safe setup on a throwaway project, with the read-only audit SQL ready to paste: github.com/cekuu35/supabase-rls-leak-demo. Clone it, run the queries against your own project, and you'll see immediately which tables are exposed.

The NEXT_PUBLIC_ question

Frameworks inline any env var prefixed NEXT_PUBLIC_ (Next.js), VITE_ (Vite), or EXPO_PUBLIC_ (Expo) directly into the client bundle. That's correct for the anon key and project URL — they're meant to be public:

NEXT_PUBLIC_SUPABASE_URL=https://xxxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGci...   # fine, this is public

The catastrophe is putting the service_role key behind a public prefix. NEXT_PUBLIC_SERVICE_ROLE_KEY ships an RLS-bypassing master key to every visitor. Service_role belongs only in server code — API routes, Edge Functions, backend jobs — under an unprefixed name.

If you exposed the service_role key

This is the one case that's a genuine incident. Do this now:

Rotate it. Supabase Dashboard -> Project Settings -> API Keys -> roll the service_role key. Every copy of the old one stops working immediately.
Purge it from git history. Deleting the file isn't enough — a committed secret lives in history forever. Use git filter-repo or BFG:

   git filter-repo --invert-paths --path .env
   # or: bfg --delete-files .env && git reflog expire --expire=now --all && git gc --prune=now

Force-push, then rotate anything else that shared that file.

The takeaway

Anon key in your bundle? Expected. Safe. Don't rotate it.
The real question is whether RLS is on and correctly scoped on every table.
Service_role key anywhere public? Rotate and purge history immediately.

Decode your key, run the two audit queries above, and you'll know exactly where you stand in about five minutes.

If you'd rather not hand-audit every policy — especially on a project with dozens of tables where one stray using (true) is easy to miss — I've packaged the full policy checklist, annotated audit queries, and a scoring rubric into a $29 RLS Audit Kit. Totally optional; the free demo repo above gets most people what they need. Either way, don't let a screenshot of your anon key ruin your afternoon. Check RLS instead.

DEV Community: Cenk KURTOĞLU

I Found 60+ Live Supabase Keys in Public Repos, So I Benchmark Whether LLMs Can Spot Them

What I Benchmarked

Models Tested

Findings

The headline: modern models are scarily good at the obvious cases

The interesting part is where they diverge

What this means in practice

What I'd measure next

Run the same checks on your own app

My Benchmark

58 of 154 public Supabase apps had a working service_role key in git

58 of 154 public Supabase apps had a working service_role key in git. Here's what that means for yours.

Why this keeps happening (it is not laziness)

The 10-second check for your own repo

If you find one — do this first

Supabase RLS: a small, evidence-first pre-launch check

Supabase RLS: a small, evidence-first pre-launch check

Five checks worth running

October 30, 2026: the Supabase change that will 42501 your next deploy - and the leak that was already there

What actually happens on October 30

The leak that was already there

What to ship so both traps are impossible

The honest version of the deadline

What to do next (Complete 10-Product CTA Ladder)

Supabase RLS returns rows it shouldn't (or throws 42501): the 6 real causes

1. RLS was never enabled (the AI-tool trap)

2. RLS enabled, but no policy matches ? everything denied

3. The USING (true) policy that looks like security

4. Missing WITH CHECK on writes

5. Dependent-policy lockout ("my admin policy is perfect but the table is empty")

6. Views, SECURITY DEFINER functions, and Storage

The service_role Key Hiding in Your .mcp.json — the AI-Vibe-Coder Secret Leak

First, get the two keys straight

Where it actually hides now

Why this is worse than the old .env mistake

Check yourself in 30 seconds

Fix it in the right order

The takeaway

The Supabase Security Checklist to Run Before You Launch

1. RLS is enabled on every table in the public schema

2. Every table has owner-scoped policies (not using (true))

3. You're using the right key in the right place

4. No secrets in the repo — or in git history

5. Storage buckets have real policies

6. Do a real self-audit before you trust the checklist

NEXT_PUBLIC_ and Supabase: Which Env Variables Are Safe to Expose?

The one rule that explains everything

Every Supabase project has two keys, and they are not equals

So, the safe list

Keeping service_role strictly server-side

Catch the mistake before it ships

If a secret already leaked

The part people forget: the anon key is only as safe as your RLS

The takeaway

You Committed .env to GitHub: What to Rotate (Supabase + Next.js)

First: which of these is actually secret?

How to tell the two keys apart

Rotating each secret

The Supabase keys

Database password

Third-party keys

Now purge git history

The part everyone skips: is your RLS actually protecting you?

The 60-second recap

Test Your Supabase RLS Policies Locally: A Free SQL Harness

How Supabase auth maps to plain Postgres

Step 1 — a minimal shim

Step 2 — a table with a policy to test

Step 3 — impersonate anon and a real user

The two mistakes worth internalizing

Step 4 — audit the whole schema at once

Wire it into CI

Where to go from here

Supabase RLS with auth.uid() not working? Causes and fixes

First, what auth.uid() actually is

Cause 1: You're on the anon key, so auth.uid() is NULL

Cause 2: RLS isn't actually enabled, so you get everything

Cause 3: You're testing with service_role, so it "works" (misleadingly)

Cause 4: Missing GRANT

3. The `USING (true)` policy that looks like security

Why this is worse than the old `.env` mistake

1. RLS is enabled on every table in the `public` schema

2. Every table has owner-scoped policies (not `using (true)`)

First, what `auth.uid()` actually is