DEV Community: Cenk KURTOĞLU

Multi-tenant RLS in Supabase: the 7 isolation bugs I find in every AI-built SaaS

Cenk KURTOĞLU — Sat, 24 Oct 2026 08:35:20 +0000

Multi-tenant RLS in Supabase: the 7 isolation bugs I find in every AI-built SaaS

I review multi-tenant Supabase security for a living. Last month I audited an AI-built admission-gate system — here are the seven isolation bugs that keep showing up, in the exact order you should check for them.

by Cenk Kurtoglu — github.com/cekuu35

1. RLS enabled, zero policies = silent deny-all (or silent chaos)

ALTER TABLE ... ENABLE ROW LEVEL SECURITY with no policies means every query returns empty — which developers "fix" by adding a policy that allows everything. Check: does every tenant-visible table have a policy set, and does every policy deny by default?

2. `USING (true)` policies that eat your restrictive ones

Postgres combines permissive policies with OR. One sloppy USING (true) policy on a table makes every other restrictive policy irrelevant — the OR chain lets anyone through. Two restrictive policies plus one permissive one = zero protection.

Check: SELECT * FROM pg_policies WHERE tablename = 'your_table'; — count permissive policies. Any USING (true) that isn't deliberate is a tenant leak.

3. Missing WITH CHECK on UPDATE

UPDATE policies have two halves: USING (can I see the row to update?) and WITH CHECK (can the row look like this AFTER my update?). Missing WITH CHECK means a tenant can update someone else's row if they can see it — or worse, mutate tenant_id itself and migrate the row into their tenant.

4. SECURITY DEFINER functions reachable by anonymous callers

An anon-reachable SECURITY DEFINER function runs with owner privileges — bypassing every RLS policy on every table it touches. Grep your migrations: every SECURITY DEFINER function needs a revoke all on function ... from public, anon and an explicit grant to the roles that need it.

5. The INVOKER/privilege contradiction that breaks your claim RPC

This one is subtle and I missed it on first pass in a recent audit (the client's own team caught it — credit where due). A claim function declared SECURITY INVOKER while the target table's INSERT privilege is revoked from authenticated (and no INSERT policy exists) means: the function executes with the caller's rights, and the inner INSERT fails with permission-denied. The function "exists and is callable" but never succeeds.

The fix: either SECURITY DEFINER with an internal auth.uid() gate and set search_path = '', or INVOKER plus a scoped INSERT policy (actor_user_id = auth.uid()). Then prove it with a three-session test: anon rejected, authenticated claims once, concurrent claim raises a serialization error.

6. Unique constraint + ON CONFLICT DO NOTHING = permanent lockout

A lease table with unique(org, tenant, run_key) and ON CONFLICT DO NOTHING prevents double-claims — but it ALSO permanently blocks legitimate re-claims after the lease expires or is revoked. The surviving row wins forever.

The fix: ON CONFLICT ... DO UPDATE SET ... WHERE your_table.lease_expires_at <= now() OR your_table.revoked_at IS NOT NULL. Live rows still conflict; dead rows yield. Add the three-session test: expired → re-claim succeeds; revoked → re-claim succeeds; live → conflict.

7. App-layer-only enforcement (the invisible single point of failure)

If your scheduler returns "reservation commands" and some unreviewed executor applies them, your atomicity lives in code nobody audited. Enforcement that isn't in the database can be bypassed by any code path that skips it.

The fix: the DB must own the invariant — constraints, exclusion rules, atomic claims. App code coordinates; the database decides.

The 20-minute self-audit

List every table with SELECT * FROM pg_tables WHERE schemaname = 'public';
For each: SELECT * FROM pg_policies WHERE tablename = ... — deny by default? WITH CHECK everywhere?
Grep migrations for SECURITY DEFINER — revoke anon on every one
Find every RPC your app calls — verify each definition's privileges and org binding
Write the three-session concurrency test for any claim/lease table

If step 2 or 4 scares you, that's the audit talking.

I do fixed-scope multi-tenant Supabase security reviews (policy matrix, negative tests, ready-to-run fix SQL) — github.com/cekuu35, cenkkurtoglu.com. I also disclose leaked keys for free, permanently.

Want the exact SQL pack? All 7 checks + fix SQL + the 3-session test, packaged for a 20-minute self-audit: Multi-Tenant RLS Self-Audit Pack - $39.

I re-verified 30 disclosed Supabase keys. 20% were still live.

Cenk KURTOĞLU — Wed, 21 Oct 2026 22:00:50 +0000

I re-verified 30 disclosed Supabase keys. 20% were still live.

The uncomfortable finding: developers who thank you for reporting a leaked key — and swear they rotated it — often don't.

by Cenk Kurtoglu — I audit Supabase/Postgres access control for a living (github.com/cekuu35)

The setup

Over the last two months I've disclosed dozens of committed Supabase service_role keys to maintainers. The workflow: find a committed key, verify it's live, email the owner with a 2-minute fix, move on. Most replies are warm: "Wow, thank you so much — I'll get that rotated immediately."

That "immediately" kept nagging at me. What does it actually mean?

So this week I ran a systematic re-verification pass: went back through my disclosure history and re-tested every project — fresh key extraction, fresh JWT decode, fresh live check against each project's REST endpoint (a single authenticated ping, no data reads, no logins).

The numbers

Out of 30 previously-disclosed repos:

State	Count	What it means
Key still committed AND still live (HTTP 200)	6	The database is readable/writable by anyone who finds the repo — right now
Key committed, project dead (endpoint paused/deleted)	14	Exposure inactive, but the key wakes up if the project is ever restored
Actually rotated and clean	12	The fix worked

One in five "fixed" projects still had a working master key sitting in public code.

The pattern that worries me

The worst case isn't the silence. It's this exact sequence, which happened twice this week:

I report a live service_role key in a committed file.
The owner replies: "Wow, thank you — I'll get that rotated and removed immediately."
Days later I re-verify: the same key, same file, still HTTP 200.

The rotation either never happened or happened to the wrong key — and the owner believes they're safe. That false confidence is more dangerous than never replying, because nobody re-checks.

One key I re-verified was issued in May — reported in October, "fixed" two days before my re-check, still live at verification time.

Why rotation fails (the ones I've seen)

The dashboard flow confuses "rotate service key" with "regenerate anon key." Both buttons look similar; only one invalidates the leaked credential.
The key lives in more than one place. They remove it from .env, forget wrangler.jsonc, .env.backup, the MCP config, the README setup section. The app keeps working — because the app still reads the old key from somewhere else — so it feels fixed.
Git history is treated as cleanup. Deleting the file from HEAD doesn't remove the key from history. That's fine only after rotation — but people do it in the wrong order and skip rotation entirely.

The 3-step check that would have caught all six

Decode the committed JWT. The payload tells you role and ref in two seconds. role: service_role + repo public = emergency.
Ping, don't assume. One authenticated GET to https://<ref>.supabase.co/rest/v1/ with the key as both apikey and Authorization: Bearer. 200 means the key is alive. 401 means rotation worked. Nothing else matters.
Rotate first, clean later. Rotate the JWT secret in the dashboard (invalidates the old key instantly), then update every location and commit. In that order, git history becomes harmless.

What I'm doing with this

I now offer rotation verification as a fixed-scope service: I re-test every key I've ever reported for you and hand you a two-line verdict — live or dead — with evidence. It's the difference between "I think I rotated" and "it's dead, here's the 401."

If you've ever committed a Supabase key: run step 2 above right now. It's one request. If you get a 200, rotate — the dashboard takes two minutes and the alternative is a stranger with full read/write on your database.

Cenk Kurtoglu — cenkkurtoglu.com · github.com/cekuu35. I disclose leaked keys for free, permanently — no payment required for the report itself.

RLS is on, so why can another user see my data? 7 Supabase surfaces that leak anyway

Cenk KURTOĞLU — Wed, 21 Oct 2026 05:48:03 +0000

You turned on Row Level Security. You wrote a policy. You tested it with your own account and it worked.

Then a user emails you: "why can I see someone else's invoice?"

This is the most common false-confidence trap in vibe-coded Supabase apps. ALTER TABLE ... ENABLE ROW LEVEL SECURITY is not a switch that makes data private. It makes a table participate in RLS. Everything else — policies, views, grants, related objects — still decides who sees what. Any one gap and the data leaks while the dashboard shows a green "RLS enabled" badge.

Here are the seven surfaces I check, in order, because they're where leaks actually hide. All queries below are read-only catalog reads you can run in the Supabase SQL editor.

1. RLS enabled but zero (or empty) policies

RLS with no policy blocks everyone except service_role. That's safe-but-broken, not a leak. The dangerous version is the opposite: RLS on, with a policy so broad it's effectively off.

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

Read the qual column. If you see true, or a role of {public}, or {anon}, that table is readable by anyone with your anon key — which is embedded in your client bundle and visible to the world.

The one I see most: a "temporary" dev policy left in:

-- the policy that ships to prod because it "worked"
create policy "allow read" on public.profiles
  for select using (true);

Fix direction: scope by ownership, not by existence.

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

2. Cross-tenant leaks from a missing `WITH CHECK` on writes

USING filters what a user can read/update/delete. WITH CHECK filters what they can insert/change into. A policy with USING but no WITH CHECK lets a user read only their rows — then write a row into someone else's tenant.

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

If with_check is null on an INSERT or UPDATE policy, an attacker with the anon key can insert rows tagged with another workspace_id/org_id.

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

3. Views bypass RLS by default

This is the one that surprises people. A normal Postgres view runs with the owner's privileges and does not apply the base table's RLS. If you built a public.user_summary view for convenience, RLS on users may be irrelevant — the view quietly exposes everything.

select table_name, security_invoker
from information_schema.views v
join pg_class c on c.relname = v.table_name
left join pg_class a on a.oid = c.relowner
where table_schema = 'public';

In Postgres 15+ (Supabase runs it) the fix is one line — make the view respect the caller's RLS:

alter view public.user_summary set (security_invoker = on);

Otherwise you're relying on grants alone, which brings us to the next surface.

4. `GRANT` to `anon`/`authenticated` overrides intent

RLS decides which rows. Grants decide whether the role can touch the object at all. A loose grant to anon on a table with a broad policy is a double hole; a grant on a table you thought was protected is often the actual vector.

select grantee, table_name, privilege_type
from information_schema.role_table_grants
where table_schema = 'public'
  and grantee in ('anon','authenticated')
order by table_name;

Look for anon + SELECT on anything containing emails, keys, or financial rows.

5. Storage buckets with public read

RLS on your tables does nothing for Storage. Buckets have their own access model. A bucket set to public serves every object to anyone who knows the URL — and object URLs are often loosely guarded in the app code.

In the dashboard: Storage → bucket → check "Public bucket". If it's on and you store user uploads there, that's your leak. Verify with a quick script hitting the public object path with the anon key — if it 200s for a file you don't own, it's open.

6. Realtime broadcasts rows RLS can't stop

Realtime starts from the anon/authenticated role and applies RLS for postgres_changes — but only if you use Row Level Security correctly and the table is in the publication. Misconfigured, a client subscribes to a table and receives change events for rows it should never see.

select * from pg_publication_tables where pubname = 'supabase_realtime';

If a sensitive table is published, confirm the subscribing user passes your SELECT policy for every row the channel delivers — not just the rows you intended to show.

7. `SECURITY DEFINER` functions re-open the door

A SECURITY DEFINER function runs as its owner — often a superuser-ish role that RLS doesn't restrict. If such a function (common in trigger helpers, e.g. an is_admin() check) is EXECUTE-able by anon, an attacker can call it directly and get owner-level access.

select p.proname, p.prosecdef as security_definer,
       pg_get_function_identity_arguments(p.oid) as args,
       r.rolname as owner
from pg_proc p
join pg_roles r on r.oid = p.proowner
where p.pronamespace = 'public'::regnamespace
  and p.prosecdef = true;

Fix direction: SECURITY DEFINER functions should set search_path = '', validate auth.uid() inside, and be revoked from anon unless truly needed.

The pattern

Every one of these leaks shares a shape: RLS was enabled, so everyone assumed the work was done. The check isn't "is RLS on", it's "for each object a low-privilege role can reach, what does it actually return?"

If you want the structured version, I keep these as seven commented SQL audit files (RLS coverage, policies, write checks, grants, bypass paths, Storage, Realtime, plus a safe BEGIN...ROLLBACK probe file) with a 60-check manual pass and an optional two-user isolation harness. The catalog queries above are the first pass; the kit is the full sweep with the report/remediation templates.

More detail and the exact file list: rls.cenkkurtoglu.com

If you're mid-launch and just want a second pair of eyes before real users sign up, that's what I do — read-only review of source, schema and policies.

The Supabase Security Checklist to Run Before You Launch

Cenk KURTOĞLU — Wed, 21 Oct 2026 05:24:01 +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 — Wed, 21 Oct 2026 05:23:15 +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 — Wed, 21 Oct 2026 05:22:29 +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 — Wed, 21 Oct 2026 05:21:42 +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 — Wed, 21 Oct 2026 05:20:56 +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 — Wed, 21 Oct 2026 05:19:26 +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.

Why Your 3D Model Won't Open on iPhone — and the No-Install GLB to USDZ Fix

Cenk KURTOĞLU — Wed, 21 Oct 2026 00:01:50 +0000

Why Your 3D Model Won't Open on iPhone — and the No-Install GLB → USDZ Fix

If you have ever sent a .glb file to someone with an iPhone and watched Safari shrug, you already know the wall: Apple's AR ecosystem does not speak glTF. iOS AR Quick Look, Safari previews, and Vision Pro all want one format: USDZ.

This is the story of that wall, why the usual tools don't help half of us, and how I ended up shipping a browser-only converter at renderivo.com/convert (first conversion free, no account) — with the technical details of what actually happens inside the conversion.

The wall, precisely

glTF/GLB is the web standard. Three.js, <model-viewer>, Shopify 3D, WebXR — they all eat GLB happily.
USDZ is Apple's AR format — a zip archive containing USDA (text scene description) plus textures. AR Quick Look on iOS literally refuses anything else for AR previews.
So any pipeline that touches an iPhone — "scan this QR code to see the product in your living room" — needs a USDZ sitting at a URL. On Android the same link works with GLB (Scene Viewer). On iPhone: USDZ or nothing.

Why the usual answers don't help

The internet's standard advice for GLB → USDZ is:

Apple's Reality Converter — macOS only. If you are on Windows or Linux, this tool does not exist for you.
Blender — can import glTF, and with the right USD plugin can export USD. Expect an afternoon of plugin archaeology, and check your materials afterwards; the glTF PBR → USD conversion path is exactly where things silently break.
Cloud converters — upload your model to somebody else's server. Fine for a sketchfab freebie; a different conversation when the model is a client deliverable under NDA.

If you have a Mac, open Reality Converter, done, happy for you. The rest of this post is for everyone else.

What a conversion actually has to do

I shipped a converter that runs the whole pipeline in the browser (the first post covers the internals). The short version:

Read the GLB with @gltf-transform (WebAssembly, in-browser — the file never leaves the machine).
Clean the geometry: weld() merges duplicate vertices, dedup() removes duplicated accessors, prune() strips unused nodes and extensions, resample() compresses animation keyframes. This is where a surprising amount of dead weight lives in marketplace assets.
Watch the textures. Two things bit me here and are worth knowing even if you never touch my tool:
- Never re-encode a texture into a different container than its declared mime type (WebP textures declared as WebP must stay WebP bytes, or viewers start guessing).
- Some Chromium builds default canvas WebP encoding to lossless — a "downsized" texture can come out 3× bigger than the original. Always pass an explicit quality, and keep the original bytes if the re-encode came out larger.
Emit USDZ with three.js USDZExporter — it builds the USDA text scene, rasterizes textures, and zips everything into a valid .usdz.

The result: one file in, two files out — the AR-ready USDZ, plus the cleaned-up GLB for the web side — with before/after sizes shown so you know what actually happened.

When you actually need this

Custom storefronts and headless commerce wiring up <model-viewer> yourself: the GLB goes in src, the USDZ goes in ios-src, and Android/iOS AR both work.
Product demos via link or QR — USDZ hosted anywhere opens straight into AR Quick Look on any modern iPhone.
Vision Pro content previews — same USDZ surface.
Client handoffs — "we need the web version and the Apple version" stops meaning installing a DCC tool.

The honest limits

Draco-compressed inputs are not supported in the current version (re-export without Draco). Morph targets don't survive the USDZ hop yet. And a 150 MB monster GLB will still make your browser fan spin — the ceiling is your RAM, not a queue.

The converter is at renderivo.com/convert — drop a file, watch it convert, download both formats. The first conversion is free and no account touches it; a one-time license unlocks unlimited conversions with no subscription.

MCP configs are the new .env files — I found live database keys committed on GitHub

Cenk KURTOĞLU — Tue, 20 Oct 2026 23:58:18 +0000

MCP configs are the new .env files. I scanned GitHub and found live database keys committed in public repos.

If you use Claude Desktop, Claude Code, Cursor or Windsurf with external tools, you have an .mcp.json or claude_desktop_config.json file on your machine. It tells your editor which MCP servers to start, and each server entry can carry an env block.

That env block is a secret store. And developers are pasting real keys into it — then committing the file.

What I found

I ran GitHub code search for filename:.mcp.json SUPABASE_SERVICE_ROLE and similar queries, then verified every result instead of trusting the match:

Decode, don't pattern-match. A file only counts if it contains a JWT whose decoded payload literally says "role": "service_role". In my scan, 53 of 65 candidate files were placeholders, templates or examples. If I had emailed all 65, four out of five would have been noise — the fastest way to teach someone to ignore security reports.
Probe whether the project is live. A leaked key for a deleted Supabase project is worthless. A GET https://<ref>.supabase.co/rest/v1/ that answers 401 (no credentials sent, nothing read) proves the project is live and the key is valid until rotated.

The result: 12 files in public repos contain a real, decodable service_role key. 4 of those projects are live right now. One of them was pushed the same day I scanned.

A service_role key bypasses every row-level-security policy. Whoever finds it has full read/write access to the database — not "some" access, all of it.

Why this keeps happening

The mental model is wrong, not the people. .mcp.json feels like editor configuration — like settings.json, like .vscode/. Nobody expects a linter or a framework to warn them, because no tool in this ecosystem treats the file as a secret store yet.

Compare with .env: a decade of leaked keys produced pre-commit hooks, secret scanners, CI checks, and platform warnings. .mcp.json has none of that guardrail history, so the same 2015-style mistakes are being made again in 2026 — just with database keys that grant more access than most API keys ever did.

Deleting the file doesn't help either: git history keeps every version forever. The only fix that works is rotating the key (Supabase Dashboard → Settings → API → rotate), then moving the new value into a runtime environment variable.

I built the linter I wanted to exist

I've spent months doing Supabase RLS audits. The configuration side of this problem needs zero-expertise tooling, so I built a family of zero-dependency auditors. Each one runs locally, reads nothing from the network, and redacts evidence in its reports so the report itself is safe to paste into an issue:

mcp-config-security — npx mcp-config-security. Scans Claude Desktop, Claude Code, Cursor and Windsurf configs for service_role JWTs (decoded, so a token hiding under a neutral key name is still caught), real-looking tokens in env/headers, --dangerously-skip-permissions flags, silent autoApprove on write tools, plaintext http:// remotes, disabled TLS verification, and filesystem servers rooted at /.
supabase-service-role-scanner — npx supabase-service-role-scanner. Walks a project for NEXT_PUBLIC_*SERVICE_ROLE* variables, NEXT_PUBLIC_ values carrying non-anon JWTs, and service_role literals in source. The anon key in NEXT_PUBLIC_ is correct by design and never flagged.
github-actions-audit — npx github-actions-audit. Static scan of workflow YAML for pull_request_target pwn requests, ${{ github.event.pull_request.title }}-style shell injection, hardcoded secrets, and unpinned actions.
firebase-rules-audit — npx firebase-rules-audit. Finds allow read, write: if true;, request.auth == null grants and conditions with no auth check at all, in Firestore and Storage rules.
n8n-workflow-audit — npx n8n-workflow-audit. Exported workflow JSON often carries tokens pasted straight into HTTP Request nodes. This flags hardcoded credentials, ?apikey= in URLs and unauthenticated webhooks — while treating n8n's own credentials: { id, name } references as the correct pattern.

All free, all MIT, no accounts, no telemetry. The companion repo supabase-rls-leak-demo covers the database side: a fixture that goes red on a broken RLS policy and green on the one-file fix.

My own tool flagged my own CIs

The first thing I ran against my own four repos was github-actions-audit. It came back with 20 findings: every actions/checkout@v4 and actions/setup-node@v4 was a mutable tag, and none of the workflows had a permissions: block.

That is the correct experience for this class of tool — it should be slightly embarrassing. I resolved the action tags to their commit SHAs (git.ref/tags/v4), pinned all four workflows, added permissions: contents: read, and pushed. Same command now exits 0. If a security linter finds nothing on its first run against your config soup, be suspicious of the linter.

What to do tonight

If you have an .mcp.json or claude_desktop_config.json anywhere in a repo — or a NEXT_PUBLIC_ Supabase variable you're not sure about:

npx mcp-config-security
npx supabase-service-role-scanner .

Two commands, a few seconds, zero installs. If they come back clean, you're done. If they don't, rotate first, refactor second.

I reported the live leaks I found privately — no bounties asked, just the rotation. If one of these tools catches something real for you, you can buy me a coffee, but the tools stay free either way.

GLB to USDZ in the Browser: How It Works and Why Your Files Never Leave Your Machine

Cenk KURTOĞLU — Tue, 20 Oct 2026 21:24:03 +0000

GLB to USDZ in the Browser: How It Works and Why Your Files Never Leave Your Machine

If you have ever tried to put a 3D model on an iPhone, you have hit this wall: iOS AR Quick Look — and Vision Pro, and Apple's AR tooling generally — only opens USDZ. Meanwhile, almost every 3D asset you download or generate arrives as GLB.

The usual options are:

Fire up Blender, import, export as USDZ, hope the materials survive.
Use a cloud converter — and upload your (possibly client-owned) model to somebody else's server.

I spent last week shipping a third option: a converter that runs entirely in the browser at renderivo.com/convert. No uploads, no accounts, works offline once the page loads. This post is the technical walkthrough — and the honest list of things that bit me along the way.

The pipeline

Three pieces do all the work, all client-side:

@gltf-transform — parses the GLB and cleans the geometry: weld(), dedup(), prune(), resample().
OffscreenCanvas — optional texture downsizing.
three.js GLTFLoader + USDZExporter — builds the AR-ready USDZ archive.

Condensed, the core of it looks like this:

import { WebIO } from "@gltf-transform/core";
import { ALL_EXTENSIONS } from "@gltf-transform/extensions";
import { weld, dedup, prune, resample } from "@gltf-transform/functions";
import { GLTFLoader } from "three/examples/jsm/loaders/GLTFLoader.js";
import { USDZExporter } from "three/examples/jsm/exporters/USDZExporter.js";

async function convert(buffer: ArrayBuffer) {
  const io = new WebIO().registerExtensions(ALL_EXTENSIONS);
  const doc = await io.readBinary(new Uint8Array(buffer));

  // 1. Geometry cleanup
  await doc.transform(weld(), dedup(), prune(), resample());

  // 2. (optional) texture resize — see gotcha #1
  // 3. Write the optimized GLB
  const optimizedGlb = await io.writeBinary(doc);

  // 4. USDZ via three.js
  const loader = new GLTFLoader();
  const gltf = await loader.parseAsync(optimizedGlb.slice().buffer, "");
  const usdz = await new USDZExporter().parseAsync(gltf.scene, { maxTextureSize: 2048 });

  return { usdz, optimizedGlb };
}

WebIO is the browser build of the I/O service — same API as the Node version, no fs involved.

Gotchas I hit shipping this

1. Never re-encode a texture into a different container than its declared mime type. GLB textures can be WebP (declared via EXT_texture_webp). My first texture-resize pass drew the bitmap to a canvas and re-encoded everything to JPEG for size — while leaving the texture's mime type as image/webp. The output declared WebP but contained JPEG bytes. Everything looked fine until you decoded it elsewhere. Keep the re-encode in the same container:

const blob = await canvas.convertToBlob({ type: texture.getMimeType(), quality: 0.85 });

2. Some Chromium builds default canvas WebP to lossless. I watched a 1024×1024 WebP texture shrink to 512×512 and grow from 146 KB to 426 KB. Passing an explicit quality (e.g. 0.85) forces the lossy encoder. Also: keep the "if the re-encode came out bigger, keep the original bytes" guard — it costs three lines and has saved every weird edge case so far.

3. Geometry cleanup preserves KHR_mesh_quantization — good, but know it. A quantized model has Int16Array positions instead of float32. weld()/dedup()/prune() operate fine on quantized data and the output stays quantized, so your 900 KB quantized model does not suddenly become a 2.4 MB float blob. If you were expecting float blowups from cleanup, you will not get them — which is exactly what you want.

4. Draco-compressed inputs are the one thing I left out of v1. The draco3dgltf npm package is an Emscripten build that require("fs") at the top level, which no browser bundler enjoys. Serving the WASM decoder properly is a v1.1 item; for now such files fail with a clear parse error and a "re-export without Draco" message. Honest limitation beats a broken bundle.

Real numbers

From the sample models I test with:

Model	Input	Output GLB (half-size textures)	Reduction
Textured owl (WebP, quantized)	962 KB	790 KB	18%
Clean geometry crate	8.5 KB	8.4 KB	~2%

Already-clean models barely shrink — that is correct behavior, not a failure. The wins come from texture-heavy marketplace assets and duplicated-vertex exports, which routinely shed 40–80%.

One more property of this architecture worth stating: the server never touches your files. Conversion happens on your device with WebAssembly; the only network call the tool ever makes is the license check against Gumroad's API when you unlock it. For anyone converting client deliverables, that is the actual selling point.

The tool

renderivo.com/convert is live:

Drop a .glb (up to 150 MB), get an AR-ready USDZ plus the cleaned GLB, with before/after sizes shown every run.
The first conversion is free, no account, no email.
Unlimited conversions is a $19 one-time license — you get a key on your Gumroad receipt, paste it once, done. No subscription, and the unlock lives in your own browser.

The full pipeline (gltf-transform + three.js + the texture-resize guard) is what ships to production — if you run into one of the gotchas above with your own models, I would genuinely like to hear about it.

DEV Community: Cenk KURTOĞLU

Multi-tenant RLS in Supabase: the 7 isolation bugs I find in every AI-built SaaS

Multi-tenant RLS in Supabase: the 7 isolation bugs I find in every AI-built SaaS

1. RLS enabled, zero policies = silent deny-all (or silent chaos)

2. USING (true) policies that eat your restrictive ones

3. Missing WITH CHECK on UPDATE

4. SECURITY DEFINER functions reachable by anonymous callers

5. The INVOKER/privilege contradiction that breaks your claim RPC

6. Unique constraint + ON CONFLICT DO NOTHING = permanent lockout

7. App-layer-only enforcement (the invisible single point of failure)

The 20-minute self-audit

I re-verified 30 disclosed Supabase keys. 20% were still live.

I re-verified 30 disclosed Supabase keys. 20% were still live.

The setup

The numbers

The pattern that worries me

Why rotation fails (the ones I've seen)

The 3-step check that would have caught all six

What I'm doing with this

RLS is on, so why can another user see my data? 7 Supabase surfaces that leak anyway

1. RLS enabled but zero (or empty) policies

2. Cross-tenant leaks from a missing WITH CHECK on writes

3. Views bypass RLS by default

4. GRANT to anon/authenticated overrides intent

5. Storage buckets with public read

6. Realtime broadcasts rows RLS can't stop

7. SECURITY DEFINER functions re-open the door

The pattern

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

2. `USING (true)` policies that eat your restrictive ones

2. Cross-tenant leaks from a missing `WITH CHECK` on writes

4. `GRANT` to `anon`/`authenticated` overrides intent

7. `SECURITY DEFINER` functions re-open the door

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