DEV Community: Cenk KURTOĞLU

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.

Your AI Coding Tool Is Committing Your Supabase service_role Key

Cenk KURTOĞLU — Fri, 14 Aug 2026 15:15:43 +0000

If you've been vibe-coding a Supabase app with Claude Code, Cursor, aider, or an MCP setup, there's a leak vector almost nobody is talking about yet: your AI tool's own config files. They quietly capture your service_role key and commit it to your repo, where bots scrape it within minutes of a push.

Here's exactly how it happens, how to check your whole repo (including history), and how to actually fix it.

First: you have two keys, and only one is a secret

Supabase hands every project two keys, and they are not equal.

The anon / publishable key is public by design. It ships in your browser bundle. It is not a secret, and you do not rotate it. Row Level Security (RLS) is what protects your data when someone hits your API with this key.
The service_role key is a server-only secret that bypasses RLS entirely — full read/write/delete on every table, plus Storage. It must never reach a browser, a public repo, or any client-side config.

There are two key formats in the wild, so know both:

Legacy JWT keys — long tokens starting with eyJ. Decode the middle segment to read the role. JWT payloads are base64*url* and unpadded, so a naive base64 -d often errors and prints nothing — which can look like a false all-clear. Normalize and pad first:

KEY="paste-your-key-here"
p=$(echo "$KEY" | cut -d. -f2 | tr '_-' '/+')
while [ $(( ${#p} % 4 )) -ne 0 ]; do p="$p="; done
echo "$p" | base64 -d 2>/dev/null | grep -o '"role":"[a-z_]*"'
# macOS: if base64 -d fails, use base64 -D

"role":"anon" is fine anywhere. "role":"service_role" committed anywhere public is a critical incident.

New keys (Supabase's 2025 format) are not JWTs — the prefix tells you everything: sb_publishable_... is public, sb_secret_... is the secret. No decoding needed. A committed sb_secret_ is the emergency.

How the AI tool leaks it

The pattern is always the same: your tool needs the key to do admin work, writes it into a config file, and that file gets committed because nobody added it to .gitignore.

Claude Code — .claude/settings.local.json. Approve an allow-listed bash command once and the literal command is saved. If you ever ran a curl with an apikey: <service_role> header, that full key now lives in the allow list.
Cursor / MCP — .cursor/mcp.json or .mcp.json. MCP servers take an env block, and the Supabase MCP server wants SUPABASE_SERVICE_ROLE_KEY right there in plaintext JSON.
Same story for .continue, aider config, and .vscode/settings.json.

Why is this catastrophic? Because service_role skips RLS. Whoever finds the key doesn't need to break your policies — the key is the break. They read every user's rows, edit balances, delete tables, and empty your Storage buckets.

Where service_role keys leak: the full checklist

Beyond AI config, these are the usual suspects. Run each from your repo root.

1. AI coding-tool config

git grep -nE 'service_role|SUPABASE_SERVICE|sb_secret_' -- \
  '.claude/*' '.cursor/*' '.mcp.json' '.continue/*' '.aider*' '.vscode/settings.json'

2. Committed .env variants — .env is usually ignored, its siblings often aren't (.env.local, .env.production, .env.staging, .env.test):

git ls-files | grep -E '(^|/)\.env'

3. The trailing-space .env trick — a .gitignore rule for .env does not match a file literally named .env (trailing space). It slips right through:

git ls-files | grep -P '\.env '   # note the space

4. The NEXT_PUBLIC_ / VITE_ / EXPO_PUBLIC_ trap — these prefixes tell your bundler to inline the value into the client bundle. NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY ships your secret to every visitor:

git grep -nE '(NEXT_PUBLIC_|VITE_|EXPO_PUBLIC_).*(SERVICE_ROLE|SERVICE_KEY)'

5. Deploy config — vercel.json env blocks, netlify.toml, wrangler.toml/.dev.vars, and railway/render/fly config:

git grep -nE 'service_role|SERVICE_ROLE|sb_secret_' -- \
  vercel.json netlify.toml wrangler.toml '.dev.vars' 'render.yaml' 'fly.toml'

6. CI and test config — GitHub Actions with inline secrets, cypress.env.json, docker-compose:

git grep -nE 'service_role|SERVICE_ROLE|sb_secret_' -- \
  '.github/workflows/*' 'docker-compose*.yml' Dockerfile
git ls-files | grep -E 'cypress.env.json|\.env.test'

7. Seed / migrate / admin scripts and committed SQL/JSON dumps — these legitimately need service_role, then get committed with the literal inlined:

git grep -nE 'service_role|sb_secret_' -- 'scripts/*' 'seed*' 'supabase/seed*' '*.sql' '*.json'

One important gotcha: a leaked legacy key is an eyJ... JWT whose payload does not contain the plaintext string service_role. If a key was inlined bare — createClient(url, 'eyJ...') — or hidden behind a generic name like SUPABASE_KEY=, every grep service_role above misses it. So also sweep for the token itself:

git grep -nE 'eyJhbGci|sb_secret_'

Check your whole repo, including history

Deleting a file today does nothing — a committed secret lives in git history forever and is recoverable from any past commit. Search history, not just the working tree. The -G flag matches the token by regex (unlike -S, which only fires when a string's count changes):

git log -p --all -G 'eyJhbGci|sb_secret_' | grep -nE 'eyJhbGci|sb_secret_'

On a large or long-lived repo, run a dedicated scanner instead — gitleaks or trufflehog also catch dangling commits the command above can miss:

gitleaks detect --source . --redact

Prefer not to eyeball this? A free repro plus read-only audit SQL that flags committed-key patterns, RLS-off tables, and anon-open policies lives here: github.com/cekuu35/supabase-rls-leak-demo. Clone it, point it at your project, done.

Found one? Rotate first, then purge history

Order matters. Rotation is what actually kills the attacker's access; purging keeps the old value out of clones and stops the next leak.

1. Rotate the key. Supabase Dashboard → Settings → API.

New keys: revoke and reissue the sb_secret_ key independently — the publishable key and user sessions are untouched. Takes 30 seconds.
Legacy keys: there's no isolated "roll service_role" button. Rotating regenerates the shared JWT secret, which also invalidates the anon key and logs out every user. Plan for it, then redeploy clients with the new anon key.

Copy the new value into your server environment before touching history.

2. Purge it from history. Using git-filter-repo (the tool Git now recommends). Put the leaked string in a file so it's scrubbed from every commit:

# expressions.txt
literal:eyJhbGciOi...your-leaked-key...==>REMOVED

pip install git-filter-repo
git filter-repo --replace-text expressions.txt
git remote add origin <your-repo-url>   # filter-repo drops the remote by default
git push --force --all
git push --force --tags

Prefer BFG? Note the format differs — no literal: prefix, and remove the file from HEAD first (BFG won't touch the tip commit):

# bfg-replacements.txt  →  one line:  eyJhbGciOi...your-leaked-key...==>REMOVED
git rm --cached path/to/leaked-file && git commit -m "remove secret"
bfg --replace-text bfg-replacements.txt
git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push --force

Forks and open PRs keep their own copies, so rotation in step 1 is what truly protects you.

Lock it down so it can't recur

Fix .gitignore carefully — a bare .env* also swallows .env.example, which you usually want committed:

.env
.env.*
!.env.example
.claude/settings.local.json
.cursor/mcp.json
.mcp.json
.dev.vars
cypress.env.json

And keep the service_role key strictly in server code (route handlers, server actions, edge functions) with a bare SUPABASE_SERVICE_ROLE_KEY name — never a public framework prefix.

Don't forget RLS itself (defence in depth)

Even with the secret safe, your anon key is public — so any table with RLS disabled or a permissive USING (true) policy is exposed to the whole internet. A few facts people mix up:

USING filters which existing rows a role can see (and scans for UPDATE/DELETE); WITH CHECK validates rows being inserted or updated.
A USING (true) SELECT policy makes a table world-readable; it only becomes world-writable if a permissive INSERT/UPDATE (or FOR ALL) policy also exists.
A role needs both a matching policy and the table GRANT to touch data.

Turn RLS on for every table in public and scope policies to auth.uid().

That's the whole loop: know your two keys, sweep working tree and history for eyJ/sb_secret_, rotate then purge, lock down RLS. If you want to go deeper, I keep a $29 RLS Audit Kit — a longer checklist covering policy edge cases, Storage rules, and the leak spots above — but the free demo repo and the commands here will catch the vast majority of real leaks.

Supabase RLS Not Working? Fix It by Symptom (Correct SQL Inside)

Cenk KURTOĞLU — Fri, 14 Aug 2026 12:22:55 +0000

Your policy looks right, the SQL editor says it works, but the JS client returns []. Or an insert throws new row violates row-level security policy. Before you rewrite anything, work this checklist top to bottom. Almost every "Supabase RLS not working" report is one of five things, and the first one is the culprit far more often than people expect.

Two ideas fix half of these before you write any SQL:

A row is reachable only when the requesting role has BOTH a matching policy AND the table-level GRANT. Public-schema tables are exposed to anon/authenticated through PostgREST's default grants; RLS + policies then decide what each role can actually do.
USING filters existing rows (SELECT, and which rows UPDATE/DELETE may touch). WITH CHECK validates new row values (INSERT, and the post-image of UPDATE). INSERT has WITH CHECK only. If you omit WITH CHECK on UPDATE/ALL, Postgres reuses USING as the check.

The #1 cause: role mismatch between test and runtime

RLS decisions depend entirely on which database role makes the request and what's in the JWT. The trap is that your SQL-editor test and your real app run as different identities.

In the SQL editor you're postgres, which — like service_role — bypasses RLS entirely and never even runs your policies. So you try to simulate a user:

set role authenticated;
select * from posts;

But set role authenticated alone leaves request.jwt.claims unset, so auth.uid() returns NULL and any policy like user_id = auth.uid() silently matches nothing. You conclude "my policy is broken" when your test was broken.

Meanwhile the JS client sends a real signed JWT (role authenticated) when there's a session, or hits the DB as anon when there isn't. Three different worlds. Verify the real one before touching a policy.

To simulate correctly, you must set the claims — and set local only lives inside a transaction, so wrap it:

begin;
  select set_config('role', 'authenticated', true);
  select set_config(
    'request.jwt.claims',
    '{"sub":"<a-real-user-uuid>","role":"authenticated"}',
    true
  );
  select auth.uid(), auth.role();   -- now returns the uuid + authenticated
commit;

Running those as three separate statements will not work — each set_config(..., true) is local to its own implicit transaction and is gone by the next line.

Symptom 1: "works in the editor, empty/failing in the app" (or vice versa)

Stop guessing and print the real identity from the real request path. The JS client can't select auth.uid() off a normal table query, so expose it through a tiny function once:

create function public.whoami()
returns table(role text, uid uuid)
language sql stable
as $$ select auth.role(), auth.uid() $$;

grant execute on function public.whoami() to anon, authenticated;

Then call await supabase.rpc('whoami') from the app. If uid is NULL where you expected a logged-in user, the client has no valid session — you're actually anon. Confirm the client uses the anon/publishable key and that getSession() returns a user.

(Side note that saves reputations: the anon/publishable key is public by design — it ships in the browser bundle, it is not a secret, and it does not need rotating. The service_role key is the one that must never reach a browser, because it bypasses RLS completely.)

Symptom 2: "select returns [] or null, no error"

An empty read is almost never a query bug. With RLS enabled, no matching SELECT policy = deny, and reads don't error — they silently return nothing. Enabling RLS with zero policies denies everything.

Check what policies actually cover reads. Note cmd can be SELECT or ALL — a FOR ALL policy covers SELECT too, so don't test for SELECT alone:

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

If nothing has cmd in ('SELECT','ALL') for your role, add one:

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

Wrap it as (select auth.uid()) — the subselect lets Postgres evaluate it once per query instead of once per row, a real win on large tables. A genuinely public table still needs an explicit to anon, authenticated using (true); no policy means no rows.

Symptom 3: PGRST116 right after a successful insert

The insert worked, yet the client throws PGRST116. Here's the exact mechanism: in supabase-js v2 an insert returns nothing unless you chain .select(). When you do .insert(payload).select().single(), the write commits, but the follow-up read is filtered by your SELECT policy — so .single() sees 0 rows and raises PGRST116 ("JSON object requested, 0 rows returned").

The fix is a SELECT policy that lets writers see their own row (the Symptom 2 policy usually covers it). If you don't need the row back, just don't call .select() after the insert.

Symptom 4: "new row violates row-level security policy" on insert

This exact string is a WITH CHECK failure — Postgres evaluated your new row against the check and it returned false. (A missing GRANT surfaces differently, as permission denied for table posts; don't confuse the two.) The usual cause: your policy requires the owner column to equal the current user, but you're not authenticated or you're not setting that column.

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

Verify (1) you're actually authenticated (Symptom 1), and (2) your insert sets user_id — explicitly, or via a column default auth.uid(). Remember INSERT has no USING; a USING clause on an insert policy does nothing.

If instead you hit permission denied for table, restore the grant:

grant select, insert, update, delete on public.posts to authenticated;

Symptom 5: "anon can still read or write when it shouldn't"

Two root causes, in order of likelihood. First, RLS may never have been enabled on the table — the single most common real-world Supabase leak. The default PostgREST grant alone exposes full CRUD, no policy required. Always confirm it's on:

select relname, relrowsecurity
from pg_class
where relname = 'posts';   -- relrowsecurity must be true

alter table public.posts enable row level security;

Second, an over-permissive policy. Permissive policies (the default) OR together, so one leftover to anon using (true) or with check (true) overrides every stricter policy beside it. Scan the pg_policies output from Symptom 2 for any true whose roles include anon or public, and drop it — or convert a guardrail to restrictive (restrictive policies AND in; one false blocks):

create policy "tenant guard"
on public.posts as restrictive for all
to authenticated
using ( tenant_id = (select auth.jwt() ->> 'tenant_id') );

One last landmine: never SELECT from a table inside a policy on that same table — it re-triggers the policy and recurses infinitely. Push membership/tenant lookups into a security definer function or a separate table.

Run the order every time

Confirm the role → confirm RLS is enabled → confirm a policy exists for that command → confirm the GRANT → read USING vs WITH CHECK. Ninety percent of RLS pain lives in those five checks.

Want to watch each symptom fail and pass locally? I keep a runnable repro — a PGlite sandbox (no cloud project needed) plus a free, read-only 9-query audit you paste into the SQL editor — at github.com/cekuu35/supabase-rls-leak-demo. It flags tables with RLS off, policies granted to anon, and USING (true) / WITH CHECK (true) shapes.

If you later want a deeper sweep across a whole schema — multi-tenant leaks, restrictive-policy interactions, storage buckets — I've packaged a more thorough checklist as an RLS Audit Kit ($29). Entirely optional; the free audit above unsticks most people today.

You shipped a Supabase app with AI. Here are the 4 security holes it probably has (and the 5-minute fixes)

Cenk KURTOĞLU — Thu, 13 Aug 2026 20:51:20 +0000

I build security tooling for Supabase, and I keep finding the same four holes in apps that shipped fast with Lovable, Bolt, v0, Cursor, or Replit. Not careless apps — good ones. Real users, real revenue, clean UIs. The people who built them aren't sloppy; they shipped a real product in a weekend, which is genuinely hard and genuinely good. But AI codegen optimizes for it works, and "it works" and "it's locked down" are two different tests. The second one rarely runs on its own.

So let me run it with you — worst first, then the thing everyone panics about but shouldn't, then the two RLS holes that actually bite, then a query you can run against your own project in 60 seconds.

1. A `service_role` key or DB password committed to the repo

This is the one that can end the whole app, so it goes first. Your service_role (secret) key has BYPASSRLS — it ignores every policy you ever wrote and has full read/write over your entire database. A Postgres connection string with the password in it is the same deal. When an AI tool scaffolds a backend it often writes both into .env, and if .env isn't ignored, one git push puts your master key out there.

Two traps people miss:

Private repos aren't safe either. Anything pushed while a repo was public is scraped almost immediately; flipping it to private afterward doesn't recall it. And collaborators, later public-ization, and breaches all expose a private repo too.
Deleting the file doesn't fix it. The secret still lives in your git history and in every clone and fork already out there.

Fix, in order — rotation is what actually saves you; the history scrub is hygiene:

# 1. Rotate FIRST, in the Supabase dashboard:
#    Project Settings -> API -> roll the service_role / secret key
#    Project Settings -> Database -> reset the database password

One caveat on rotation: check which key model your project is on. Newer projects use sb_secret_ / sb_publishable_ keys that can be revoked individually. Older projects use the legacy JWT-based keys, where regenerating the JWT secret rotates the anon key at the same time and drops every logged-in session — so plan for that.

# 2. Then purge it from history. Run this on a FRESH full clone:
pip install git-filter-repo
git filter-repo --path .env --invert-paths --force
git remote add origin <your-repo-url>   # filter-repo drops the remote by design
git push --force --all
git push --force --tags                 # a key can sit in a tagged commit too

History rewriting doesn't reach existing forks, open PRs, or GitHub's caches — which is exactly why step 1 is the real mitigation. Going forward: service_role lives only on a server or in Edge Function secrets, never in the browser bundle, never in the repo. Add .env and .env.* to .gitignore today.

2. Relax — your `anon` key is supposed to be public

Half the panic I see is misdirected here. The anon key (Supabase now also calls it the publishable key) is public by design. It ships in your client bundle on purpose. You do not need to rotate it, and finding it in your JS is not a breach. I've watched people burn a weekend "fixing" this while the real hole sat untouched.

The anon key isn't a password — it's a name tag that says "unauthenticated visitor." It's low-privilege on its own; what it can actually touch is decided by table grants plus Row Level Security. Which is exactly why the next two holes are the ones that matter.

3. RLS off, or a policy that says `USING (true)`

On most Supabase projects, tables in the public schema get default grants for the anon role and are exposed through the Data API. So if RLS is off, the anon key reads every row. A policy of FOR SELECT USING (true) with no TO clause is the same thing — it applies to everyone, anon included.

Turn RLS on and scope reads to the owner:

alter table public.profiles enable row level security;

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

enable row level security with no policy means deny-all — you then add back exactly what each role should see. The to authenticated keeps anon out entirely.

4. The write leak: reads and writes use different rules

This is the subtle one, and the one AI gets wrong most. Two different expressions guard a table:

USING filters which existing rows you can see or touch (SELECT, UPDATE, DELETE).
WITH CHECK validates the new row's values (INSERT, and the post-update row).

INSERT has WITH CHECK only. So this — which looks locked down — lets anyone signed in insert a row as any user:

-- BAD: new row can carry any user_id
create policy "add" on public.posts
  for insert to authenticated
  with check (true);

-- GOOD: the new row must belong to the caller
create policy "add own" on public.posts
  for insert to authenticated
  with check (auth.uid() = user_id);

Three things worth memorizing:

FOR ALL USING (true) with no WITH CHECK reuses that true as the write check too — reads and writes are open.
A FOR UPDATE ... USING (auth.uid() = user_id) with no WITH CHECK is actually safe: Postgres reuses USING as the check, so an attempt to hand a row to another user bounces.
Permissive policies OR together — one true anywhere reopens that command for every role that policy applies to, and a tight policy can't claw it back.

The 60-second self-check

Run this in the Supabase SQL editor, against your live project:

-- 1. Tables with RLS off (ignore extension/reference tables like spatial_ref_sys):
select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

-- 2. anon/public policies that over-share reads or let anyone write:
select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public' and permissive = 'PERMISSIVE'
  and ('anon' = any(roles) or 'public' = any(roles))
  and (qual = 'true' or with_check = 'true');

-- 3. authenticated write policies open to any logged-in user (the cross-tenant leak):
select tablename, policyname, cmd, roles, with_check
from pg_policies
where schemaname = 'public' and permissive = 'PERMISSIVE'
  and 'authenticated' = any(roles)
  and cmd in ('INSERT', 'ALL')
  and (with_check = 'true' or with_check is null);

A clean result lowers your risk but doesn't prove safety. These queries only match the literal string true, so functionally-open predicates like using (1=1) or using (user_id = user_id) slip through — eyeball anything with a suspiciously broad qual. And a for select to authenticated using (true) still lets every logged-in user read every tenant's rows, so give authenticated-scoped reads a second look too.

One honest caveat: RLS is often configured in the Supabase dashboard, not in committed SQL — so "there's no policy in my repo" proves nothing about production. The live query above is the only source of truth.

None of this makes you a worse builder for shipping fast. Shipping fast is the whole point; you just want the "locked down" test to run once too. Turn RLS on, scope to auth.uid(), keep service_role off the client, and let the anon key be exactly as public as it was always meant to be — and the fast path stays the safe one.

If you want to watch the RLS side of this fail and then a one-line policy change close it, I put a small reproducible project here: github.com/cekuu35/supabase-rls-leak-demo — it runs Postgres locally (PGlite, no Supabase account or credentials needed; npm ci && npm run test:ci), and the isolation tests flip from failing to passing once the right policies are in place. It also ships a free, SELECT-only audit/rls-audit.sql — nine catalog queries you can paste straight into the Supabase SQL editor.

If you'd rather hand someone a done-for-you checklist across a whole project, a Supabase RLS Audit Kit exists — but honestly, the repo and the query above catch most of what I find.

New Row Violates Row-Level Security Policy: The Real Fix

Cenk KURTOĞLU — Thu, 13 Aug 2026 20:18:31 +0000

I build tooling that scans Supabase projects for Row Level Security mistakes, and I keep running into the same reassuring, wrong mental model: "RLS is on, my SELECT policies are scoped to auth.uid(), so my data is locked." The read side often is fine. The trouble is that reads and writes go through different doors, and most audits only check the one they can see.

Reads and writes are checked by different expressions

A Postgres RLS policy has two halves:

USING — the visibility filter. It decides which existing rows a query can see (SELECT, and which rows an UPDATE/DELETE is allowed to touch).
WITH CHECK — the write filter. It decides which new row values are allowed to land (INSERT, and the post-image of an UPDATE).

The catch is in how they default:

INSERT policies have WITH CHECK only. There is no USING to fall back on — an insert has no existing row to filter.
UPDATE policies check USING against the old row and WITH CHECK against the new row. Omit WITH CHECK, and Postgres reuses the USING expression as the check.
FOR ALL applies USING to reads and to the old-row side of UPDATE/DELETE, and WITH CHECK to the new row on INSERT/UPDATE — and again, omit WITH CHECK and USING is reused.

Your read-audit greps for SELECT policies and confirms they say auth.uid() = user_id. It never reads the write filter. That's the blind spot.

Leak #1: `WITH CHECK (true)` on INSERT

Here's a table where reads are perfectly locked down:

create policy "read own messages"
on public.messages for select
using ( auth.uid() = user_id );

And here's the door someone left open, usually to "just get inserts working":

create policy "allow inserts"
on public.messages for insert
with check ( true );

with check (true) accepts every new row. A policy with no TO clause applies to public — every role, anon included. So anyone holding the public anon key can insert a row with user_id set to someone else and write straight into another user's inbox, feed, or audit log. Reads are locked; writes are wide open.

The fix is to make the write filter say what the read filter says:

create policy "insert own messages"
on public.messages for insert
with check ( auth.uid() = user_id );

The subtlety: `FOR ALL USING (true)`

This one trips up even careful people, so let's be exact about what is and isn't a bug.

A USING-only UPDATE is safe:

create policy "update own todos"
on public.todos for update
using ( auth.uid() = user_id );      -- no with_check

Because WITH CHECK is omitted, Postgres reuses auth.uid() = user_id as the write check. Try to rewrite user_id to another account and the new row fails that reused check:

new row violates row-level security policy for table "todos"

So with_check IS NULL on an UPDATE is the safe shape, not the leak. Don't let an audit flag it.

Now the actual leak — same reuse rule, opposite outcome:

create policy "manage own todos"
on public.todos for all
using ( true );                      -- no with_check

USING (true) already over-shares — it exposes every read and every delete across the table. But with no WITH CHECK, that true is also reused as the write check, so an INSERT, or an UPDATE that rewrites user_id, lands cleanly too. In pg_policies this shows as qual = true, with_check = null: the one place a null with_check is genuinely dangerous, because the qual it inherits is true.

Permissive policies OR together

Multiple permissive policies for the same command combine with OR — one policy that passes anywhere is the whole verdict. So this, sitting quietly beside your correct policy:

create policy "service writes"
on public.todos for all
with check ( true );

silently re-opens every write, however good its neighbor is. And it surfaces as cmd = 'ALL', not INSERT/UPDATE — exactly why an audit that filters only for INSERT and UPDATE walks right past it.

A write-leak detection query

Run this against your project. It flags the anon/public write policies that let anyone write, and deliberately spares the safe USING-only update:

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
  and cmd in ('INSERT','UPDATE','ALL')
  and ('anon' = any(roles) or 'public' = any(roles))
  and ( with_check = 'true'
        or (cmd = 'ALL' and qual = 'true' and with_check is null) );

Reading it clause by clause:

cmd in ('INSERT','UPDATE','ALL') — writes only, and 'ALL' is in there because a stray FOR ALL WITH CHECK (true) surfaces as cmd = 'ALL', never as INSERT/UPDATE. Leave it out and you miss the most common way a good schema gets quietly re-opened.
'anon' = any(roles) or 'public' = any(roles) — this scopes the scan to the anon-key path, the highest-severity, false-positive-free class: anyone with your public key. qual and with_check are text columns, so these are string comparisons against the literal 'true'.
with_check = 'true' — catches explicit permissive checks, including FOR ALL WITH CHECK (true).
cmd = 'ALL' and qual = 'true' and with_check is null — catches USING (true) being reused as the check.

A bare with_check IS NULL term is intentionally not here — it would flag the safe USING-only update and bury you in false positives. One honest caveat: this query targets the anon/public class. Over-permissive writes scoped TO authenticated (any logged-in user writing another tenant's rows) are a real but separate, narrower class — widen the role filter if you want to sweep for those too.

It's the policy, not the key

When people find one of these, the first instinct is often to rotate the anon key. Don't bother. The anon key is public by design — it ships in your client bundle, and it's meant to. It isn't a secret, and rotating it fixes nothing. The vulnerability is the policy that lets a caller in the anon/public scope write where it shouldn't. Fix the WITH CHECK, not the key.

If you'd rather feel this than take my word for it, I put together a small reproduction: github.com/cekuu35/supabase-rls-leak-demo stands up the leaky policies, shows a cross-tenant write succeeding, then applies the fix — so you can confirm your own detection query catches it before someone else does.

For teams who'd rather not hand-roll the checklist, I also keep a paid Supabase RLS Audit Kit — though honestly, the query above and an afternoon will get most projects there.

Supabase Storage Upload Fails With RLS (403: new row violates row-level security policy)

Cenk KURTOĞLU — Wed, 12 Aug 2026 15:47:52 +0000

Originally published on cenkkurtoglu.com.

Your upload throws new row violates row-level security policy (HTTP 403) — but the exact same upload works with the service_role key. That one detail is the whole diagnosis: files in Supabase Storage are rows in the storage.objects table, RLS applies to that table, and service_role bypasses RLS. So the key is not the fix — your storage.objects policy simply does not match the request you are actually making.

Why service_role "works" and your app key does not

service_role ignores every policy, so a successful upload with it proves nothing about your rules. Your browser or server upload runs as anon or authenticated, and those go through RLS on storage.objects. If no policy grants an INSERT to that role for that bucket, you get the 403.

The four things that actually cause it

Role mismatch. You are uploading with the anon key and no signed-in session, so the request is anon — but your policy targets authenticated. Either sign the user in first, or add an explicit anon policy if public uploads are intended.
"Public bucket" is not "public writes." Making a bucket public only affects reads. Uploading still needs an INSERT policy on storage.objects.
Missing bucket_id match. A policy that does not scope to your bucket will not apply. Check bucket_id = 'your-bucket'.
Per-user folder rule not met. A common pattern requires the first path segment to equal the user id; if you upload to a different prefix, the WITH CHECK fails.

A working authenticated-upload policy

For "each signed-in user can upload into their own folder in the avatars bucket":

create policy "authenticated users upload to own folder"
on storage.objects for insert
to authenticated
with check (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = auth.uid()::text
);

Upload to the path avatars/<user-id>/file.png and it passes. Upload to any other prefix and RLS correctly rejects it.

Confirm which role your upload runs as

select auth.role() as role, auth.uid() as uid;

If it returns anon while your policy expects authenticated, the request is unauthenticated — that is the real problem, not the policy.

Check every policy and role (including storage.objects) in one pass with the Supabase RLS Audit Kit ($29) — 60 checks plus a role-simulation harness that proves isolation. Free read-only demo (runs in ~2s, no Docker): github.com/cekuu35/supabase-rls-leak-demo.

DEV Community: Cenk KURTOĞLU

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

Cause 5: Missing (or wrong) TO clause

Cause 6: Comparing a uuid to a text column

The policy pattern to standardize on

A 60-second self-audit

The takeaway

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

Every Supabase project has two keys

Decode the key to find out which one you have

Why is the anon key safe to make public?

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

The NEXT_PUBLIC_ question

If you exposed the service_role key

The takeaway

Your AI Coding Tool Is Committing Your Supabase service_role Key

First: you have two keys, and only one is a secret

How the AI tool leaks it

Where service_role keys leak: the full checklist

Check your whole repo, including history

Found one? Rotate first, then purge history

Lock it down so it can't recur

Don't forget RLS itself (defence in depth)

Supabase RLS Not Working? Fix It by Symptom (Correct SQL Inside)

The #1 cause: role mismatch between test and runtime

Symptom 1: "works in the editor, empty/failing in the app" (or vice versa)

Symptom 2: "select returns [] or null, no error"

Symptom 3: PGRST116 right after a successful insert

Symptom 4: "new row violates row-level security policy" on insert

Symptom 5: "anon can still read or write when it shouldn't"

Run the order every time

You shipped a Supabase app with AI. Here are the 4 security holes it probably has (and the 5-minute fixes)

1. A service_role key or DB password committed to the repo

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

1. A `service_role` key or DB password committed to the repo

2. Relax — your `anon` key is supposed to be public

3. RLS off, or a policy that says `USING (true)`

Leak #1: `WITH CHECK (true)` on INSERT

The subtlety: `FOR ALL USING (true)`