Key formats are changing (sb_publishable_ and sb_secret_); the docs state anon and service_role keys are deprecated by end of 2026.
Supabase is a hosted Postgres with an auto-generated API, auth, storage and edge functions. Its access model is the source of most public incidents in AI-built apps: the publishable (anon) key is meant to be public, and row-level security policies decide what that key can reach.
Supabase's docs state three things. Tables created in the dashboard get RLS enabled and tables created by SQL do not. The secret (service_role) key bypasses every policy. The Security Advisor flags tables without RLS. The checks below confirm those facts hold for your project.
Each row is taken from the vendor's documentation on the date shown. Defaults change; the date is the claim.
| Area | Default | Source |
|---|---|---|
| RLS on new tables (dashboard vs SQL) | The Table Editor enables row level security when you create a table in the Dashboard; when you create a table with SQL you must enable it yourself. | docs · verified 2026-09-21 |
| Tables without RLS | On existing projects a new table in public starts with every privilege granted to all three roles. A table in an exposed schema without RLS is readable and writable by any role with a grant on it. | docs · verified 2026-09-21 |
| Anon / publishable key exposure model | Publishable keys (sb_publishable_, formerly anon) are safe to expose in web pages, apps and source code; anyone can read them, so they reach only what RLS allows, as the anon or authenticated role. | docs · verified 2026-09-21 |
| service_role / secret key scope | Secret keys (sb_secret_, formerly service_role) have BYPASSRLS and skip every RLS policy; the docs say never to put one in a browser, shipped app or source control. Legacy anon and service_role JWT keys are being deprecated by end of 2026. | docs · verified 2026-09-21 |
| Edge function auth | verify_jwt = true is the default and validates the JWT before the handler runs; with auth: 'none' every credential check is skipped and the handler must authorize itself. | docs · verified 2026-09-21 |
| Storage access | Storage does not allow uploads to buckets without RLS policies on storage.objects; public buckets are publicly readable; service keys bypass Storage RLS. | docs · verified 2026-09-21 |
Documentation home: supabase.com/docs
45 patterns in the catalogue name Supabase; the most severe are listed here across secrets and keys, data access, login and permissions, payments, ai features. Attribution is descriptive: the default stack makes the pattern reachable, or a public incident names it.
The build writes the secret's value into public JavaScript, so anyone who loads the site can read it, and a redeploy with the same variable name republishes it.
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
Anyone who opens the app can copy the key from the downloaded JavaScript and read, change or delete every row in every table.
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
Signed-out visitors or other customers can read rows meant for one account, while the owner sees an empty page and nobody notices.
Anyone who creates a free account can page through every other customer's records, which is a data breach with a sign-up form as the only step.
Anyone with the project URL and the public anon key, both of which sit in the app's JavaScript, can read, edit or delete every row in the table.
The table looks protected in the dashboard, yet any visitor with the public anon key can read, insert, update and delete every row.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.
Anyone who reads the code or guesses a common placeholder can sign in as the administrator.
Anyone can write their own token naming another user, or an admin, and the server will act as that person.
A visitor who edits the signup request, or updates their own profile, can make themselves an admin.
Anyone who finds the webhook URL can post a made-up payment-succeeded event and get an order fulfilled or a plan activated for a user of their choosing, without paying.
Anyone who views the page source can copy the key and run their own workloads on your account until the bill or the provider stops them.
A scan of 1,645 Lovable-built apps found 170 (about 10.3%) with database endpoints readable without login because Supabase row-level security policies were missing or too broad; recorded as CVE-2025-48757, CVSS 9.3.
May 2025 · Matt Palmer (Replit, Inc.) · all sources
Moltbook, a social network for AI agents built with AI-generated code, ran a Supabase database without row-level security policies, leaving 1.5 million API tokens and 35,000 email addresses readable and writable without login.
Feb 2026 · Wiz Research · all sources
One education app built on Lovable had 16 vulnerabilities, 6 critical; a database function denied callers whose role was 'authenticated', so anonymous callers passed and 18,697 user records were readable without login.
Feb 2026 · Taimur Khan · all sources
Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects; a fix shipped within two hours.
Apr 2026 · Lovable · all sources
Each entry links to its primary source in the evidence list. What to do about it is the self-check below.
Stated from the vendor's documentation. The limits are the vendor's scope statements, not judgements.
Security Advisor and database lints
Advisors run automatically in Studio and via CLI, MCP and the Management API, with ERROR-level lints such as rls_disabled_in_public, auth_users_exposed, sensitive_columns_exposed and WARN lints such as permissive_rls_policy (USING (true)).
Where it stops: Checks schema configuration and policies; findings need manual confirmation against the intended schema, and runtime behaviour or application logic is outside their scope.
vendor docs · verified 2026-09-21
Row Level Security
Per-row Postgres policies that apply to publishable-key traffic; the RLS guide covers writing policies and testing them with pgTAP via supabase test db.
Where it stops: Policies do not apply to secret-key traffic (service_role bypasses RLS) and must be enabled on SQL-created tables.
vendor docs · verified 2026-09-21
Production checklist controls
SSL enforcement, network restrictions, account MFA, email confirmations and rate limits (for example 2 emails per hour on the default SMTP) are documented dashboard settings.
Where it stops: These are settings to turn on; the checklist lists them as steps rather than defaults.
vendor docs · verified 2026-09-21
Auth and storage controls
The product security page lists row and column level security, bot detection for auth, storage access control via RLS and custom roles.
Where it stops: The page is an index of features; each needs configuration in the linked guides.
vendor docs · verified 2026-09-21
The critical patterns first. Each uses the dashboard and your browser.
.env files, list every variable whose name starts with NEXT_PUBLIC_.NEXT_PUBLIC_ variable holding a server-only key, or a search hit for that key's value in a loaded script..env, .env.local, .env.production, serviceAccountKey.json or firebase-adminsdk files.sk_live, sk-, service_role, BEGIN PRIVATE KEY and password=.git log --all -p -S sk_live -- . | head. Any output means a live key has been committed at some point.service_role and then for sb_secret_.supabase.co, and read the apikey header under Request Headers.Supabase pre-launch checklist
45 checks, in the order we run them. Usable without buying anything.
Self-check tool
Answer questions about your setup and get the patterns that apply, ordered by severity. Runs in your browser; nothing is sent.
For founders about to let real users in.
$490
For anyone who wants the three riskiest areas checked fast.
$290
All packages and prices. Every report includes a re-check after your fixes.
For every table your app touches: is RLS enabled, does each policy use auth.uid() or a role check rather than true, and can the publishable key read rows that belong to another user. We test each table with the anon key and two signed-in users and report which ones leak.
Open the SQL editor and run the query on the rls-disabled pattern page, or open Database Advisors and look for RLS Disabled in Public and Permissive RLS Policy. Then sign in as a second test user and try to load the first user's data in the app.
Yes, by design: Supabase's docs say publishable keys are safe in web pages and source code because RLS decides what they can do. The key that must never reach the browser is the secret (service_role) key, which bypasses every policy.