Home › Tools › Supabase security checklist

Supabase security checklist: RLS, auth, keys and storage for Next.js and Lovable apps

A free, copyable checklist for apps built on Supabase, whether hand-written in Next.js or generated by Lovable, Bolt, v0 or Cursor. Each item says what to look for, why it matters, and the fix. It came out of a static code review of three open-source Supabase + Next.js starters.

Updated 2026-10-09 · Checked against the current Supabase docs (Auth SSR, API keys, Storage, RLS). Static review only; nothing here asks you to attack a system you don't own.

1. The 10-minute A/B test scanners can't do

Scanners (Supabase Security Advisor, Lovable's scans, open-source linters) check policy shapes and known misconfigurations. They don't know which rows belong to which customer. This test does.

1. Create two normal accounts in your app: A and B. Create some private data as A.
2. Signed in as B, call the API directly (browser console or a script using the publishable key and B's session): read A's rows by id, list the table with your app's filters removed, update A's row, delete A's row.
3. As B, insert a row with A's user_id (or org_id / workspace_id), and try to update your own row to set the owner column to A.
4. Check the row count, not the status code. When RLS filters out an UPDATE or DELETE, the request still succeeds and simply affects zero rows. "No error" does not mean "blocked", and it does not mean "allowed".
5. Repeat everything signed out (the anon role).
6. Do the same for storage paths, RPC functions and your own server routes. Re-run it after every migration or AI edit that touches policies; Supabase supports SQL policy tests under supabase/tests/ run with supabase test db.

// as user B, with the normal browser client
const { data, error } = await supabase
  .from('invoices').update({ amount: 0 })
  .eq('id', A_INVOICE_ID).select();
// expect: error == null AND data.length === 0  (blocked)
// data.length === 1 means B just changed A's row

Want the read, update and storage parts scripted? supabase-rls-ab-test is a free, MIT-licensed Python script (no dependencies) that signs in as A and B with your publishable key and reports any row B can read or update. Read-only unless you pass --write, and that write is a no-op. Run it on staging.

2. Row Level Security and grants

• RLS is enabled on every table in an exposed schema (public by default). Tables created in the Dashboard Table Editor get RLS on by default; tables created with raw SQL or migrations need alter table ... enable row level security. A table that is granted to anon/authenticated with RLS off is readable and writable by anyone with your publishable key. Critical if it holds user data
• Grants are deliberate. Postgres checks grants first, then RLS. On existing projects, new tables in public have historically been auto-granted to anon, authenticated and service_role. Supabase is turning that off: new projects since May 30, 2026, and existing projects for newly created tables from October 30, 2026. After that, a new table without a grant fails with 42501 permission denied. Don't "fix" that with grant ... on all tables in schema public to anon; grant only what each role needs, in the same migration that creates the table.
• No using (true) / with check (true) on private tables. Public catalog tables (products, prices) are fine; profiles, orders, messages are not.
• INSERT and UPDATE policies pin ownership in with check. INSERT policies only take with check, so make it (select auth.uid()) = user_id, not true. For UPDATE, Postgres reuses using as the check when with check is omitted; that's safe only if the expression pins the owner column. A permissive with check lets a user hand a row to someone else, or create rows owned by another user.
• Ownership comes from auth.uid() or verified membership, never from a request-supplied id. The owner column is not null and references auth.users. Don't base policies on user_metadata, which users can edit themselves (Security Advisor lint 0015).
• Views and SECURITY DEFINER functions are reviewed separately. Both can bypass RLS. Pin search_path on definer functions (lint 0011) and revoke execute from anon/public on anything that shouldn't be callable from the browser.
• Security Advisor is clean, or every remaining finding is explained. Run it in Studio (Database › Security Advisor) or with supabase db advisors. Useful, but it can't replace the A/B test.

3. Keys and secrets

• Only the publishable key (sb_publishable_...) or legacy anon key reaches the browser. These are public by design; RLS is what protects data.
• The secret key (sb_secret_...) and legacy service_role key never reach the browser. They bypass RLS entirely. Search your built JS (.next/static, dist/) for service_role, sb_secret_ and long eyJ... strings. Critical
• Nothing secret behind NEXT_PUBLIC_ / VITE_. Those prefixes are bundled into client code.
• Server files that create an admin client never get imported into a client component (no 'use client' in the import chain; consider the server-only package).
• No real keys in committed .env files or git history. If a secret leaked, fix the cause, then rotate it in Settings › API Keys.
• Supabase is retiring legacy anon/service_role keys by end of 2026. Plan the move to publishable/secret keys.

4. Server auth: getClaims / getUser vs getSession

• Server code decides who the user is with getClaims() or getUser(), never with getSession(). From Supabase's Next.js SSR guide: "Never trust supabase.auth.getSession() inside server code such as Proxy. It reads the session out of the cookie without revalidating it." getClaims() verifies the JWT signature (locally on projects with asymmetric signing keys); getUser() asks the Auth server for the current user record. In a local test, an unsigned, forged cookie came back from getSession() on the server as a fully populated user. Medium to high, depending on what that user id unlocks
• Watch where the user id goes. The dangerous pattern is session.user.id from getSession() flowing into a service-role query, a Stripe customer lookup or a billing portal link. RLS doesn't help there because the secret key bypasses it.
• The Next.js middleware (proxy.ts in Next.js 16, middleware.ts before) refreshes the session and protected routes fail closed. Look for guards that are commented out, or route lists that miss new pages. Middleware is not the only gate: every Server Action and Route Handler that touches private data checks the user itself.
• Session responses aren't cached. If you use ISR or a CDN, a cached Set-Cookie can sign one visitor in as another. Apply the cache headers @supabase/ssr passes to setAll.
• Sign-up abuse: email confirmation on, a sensible minimum password length, CAPTCHA (Turnstile or hCaptcha) on public sign-up, and anonymous sign-ins off unless you use them (lint 0012).

5. Edge Functions and API routes

• Every function or route that uses the secret key checks the caller first (a verified user via getClaims()/getUser(), a shared secret, or a webhook signature). A service-role endpoint with no caller check is an open admin API. High
• Don't rely on verify_jwt alone. Supabase notes that with the new publishable/secret keys, passing the verify_jwt check doesn't authenticate the caller; authorize in code. If verify_jwt = false (common for webhooks), the function must do its own check.
• Webhooks verify signatures on the raw body (stripe.webhooks.constructEvent, svix, etc.).
• RPC / server functions taking a user_id parameter ignore it and use the authenticated user, or check that it matches.

6. Storage buckets

• Public buckets are public for reads. Supabase docs: a public bucket bypasses access control for retrieving and serving files, so anyone with the URL can download them. Uploading, deleting, moving and copying are still controlled by policies. Fine for avatars and blog images; wrong for invoices, IDs or private uploads. Buckets are private by default.
• Private-bucket policies on storage.objects scope to the user, typically bucket_id = 'docs' and (storage.foldername(name))[1] = (select auth.uid())::text. A policy that only checks bucket_id lets every signed-in user read every file. High
• Test list, download, upload, overwrite and delete separately as user B against A's folder. Upsert needs select and update permissions too.
• Signed URLs have short expiries, and upload paths are built server-side or sanitized, not taken verbatim from the client.

7. Redirects and OAuth

• Post-login redirects only go to relative, same-origin paths. A raw ?next= or ?redirect= used verbatim is an open redirect.
• Redirect URLs aren't built from Host / X-Forwarded-Host unless your platform pins those headers.
• The Auth redirect allow-list is tight in production (no wildcard localhost or preview domains you don't control).

8. Referral attribution (the money bug)

• ?ref= / UTM survives the OAuth round trip. signInWithOAuth sends the user to Google or GitHub and back to a fixed redirectTo; the query string from the landing page is gone. Referred signups then look organic and partners aren't credited. Fix: store the ref in a first-party cookie (or an allow-listed redirectTo parameter) before redirecting, then read it server-side in the callback.
• Attribution is written server-side, once, and can't be forged by the client. If the browser writes referred_by directly, users can self-refer or credit anyone. Write it in the callback (or in a SECURITY DEFINER function with a pinned search_path that uses auth.uid() and only sets the value when it's empty). Check that the referrer exists.
• Self-referral is blocked and rewards are idempotent per referred user (no double credit on retries).

9. Lovable and other AI-built apps

Lovable apps store data in Supabase, so everything above applies. Lovable runs a free Quick scan on every publish and offers an on-demand Deep scan (More › Security). Run both. Lovable's own docs say these tools "do not replace a thorough security review". In practice the gaps are the ones a scanner can't infer:

• Which rows belong to which customer or team (run the A/B test above).
• Lead or contact forms: the table should allow insert for anon and nothing else. Watch for .insert(...).select(): returning the new row needs a select policy, and the usual "fix" opens select to everyone. Drop the .select() instead.
• Edge Functions the AI wrote with the secret key and no caller check.
• Policies that changed after the last scan. Re-test after every prompt that touches the database.

10. What showed up in 3 open-source starters

We ran this checklist against three public Supabase + Next.js starters (code only, pinned commits, no live systems contacted): vercel/nextjs-subscription-payments, KolbySisk/next-supabase-stripe-starter and Razikus/supabase-nextjs-template.

• Server authorization built on getSession() in one starter, feeding a service-role Stripe customer lookup and billing-portal route, with the middleware route guard commented out. Exploiting it still needs the victim's user id, so it's high, not critical.
• ?ref= / UTM lost on OAuth sign-in in all three (constant redirectTo, nothing read in the callback).
• Smaller items: full DML (including truncate) granted to anon on a table protected only by RLS; SECURITY DEFINER trigger functions without a pinned search_path; a real project .env committed in one template.
• Verified fine: public products/prices catalog policies, Stripe webhook signature checks, upload paths scoped to the user's folder.

FAQ