Use case

Supabase RLS Check

Row Level Security is the most important Supabase setting most AI-built apps get wrong. When RLS is disabled, every table is readable by any visitor with the anon key — and the anon key is almost always in the client bundle. GetLeaked checks your public app surface for this combination before you ship it to users.

Check your Supabase app freeSee pricing

What Row Level Security does and why it matters

  • RLS (Row Level Security) is a PostgreSQL feature that controls which rows a query can return based on the user making the request.
  • When RLS is enabled on a table, a SELECT without a matching policy returns zero rows — even with the anon key.
  • When RLS is disabled, any authenticated or anonymous Supabase client can read every row in that table.
  • Supabase enables RLS by default on new tables in recent dashboard versions, but older tables and tables created via migrations may have it disabled.

The common failure pattern

Lovable, Bolt, and v0 generate Supabase code quickly. The generated code often uses the anon key for client-side queries without confirming RLS is enabled. The resulting app appears to work correctly because the developer is authenticated and sees their own data — but unauthenticated visitors can also read every row.

What GetLeaked checks

Four signals that indicate RLS risk.

01

Supabase anon key exposure

The Supabase anon key is designed to be public — it is safe to ship to the browser when Row Level Security is on. But it becomes a data access key when RLS is disabled on a table. GetLeaked checks whether your anon key is exposed in client bundles, which it flags so you know to verify your RLS policies.

02

Direct client-side table queries without auth context

Supabase client calls in browser code that run without a Supabase Auth session use the anon key by default. If RLS is disabled on the target table, those queries return all rows to any visitor. GetLeaked looks for Supabase client initialization patterns in client bundles and flags queries that appear to run in an unauthenticated context.

03

Missing RLS signals in client calls

Calls to Supabase that use .from(tableName).select() without an explicit auth.uid() filter in the policy, or without a session from getUser() / getSession(), are candidates for full-table reads if RLS is off. GetLeaked flags these patterns so you can verify the corresponding policy in the Supabase dashboard.

04

Service role key exposure

The Supabase service role key bypasses all RLS policies entirely. If it appears in a client bundle, any visitor can read and write every table. GetLeaked checks for service role key patterns specifically, separate from anon key checks, because the severity is categorically different.

Scope and limitations

GetLeaked checks client-side signals. For definitive RLS confirmation, check the Supabase dashboard.

  • GetLeaked cannot directly query your Supabase project — it checks your public app surface for signals that suggest RLS risk.
  • Confirming RLS status requires checking the Supabase dashboard under Table Editor → RLS or using the Supabase CLI.
  • The free scan checks client bundle patterns. Deep Scan expands the public-deployment review with additional Supabase exposure signals and remediation notes.

Verify your Supabase app before users find the gap.

Paste your public URL and get a report on anon key exposure and client-side Supabase call patterns in minutes. Free, no login required.

Scan public URL — freePricing