Can Supabase apps be hacked?

Most Supabase Security Issues: Missing RLS

The majority of Supabase security incidents stem from tables without Row Level Security enabled. When RLS is disabled, anyone with your anon key can read, modify, or delete all data in that table.

Supabase-Specific Attack Vectors

These are the paths attackers actually take into Supabase applications — not a generic OWASP list, but what automated scanners and security researchers find when they look at Supabase apps specifically, given the stack (Supabase (Postgres + RLS) as the database):

1. **Tables Without RLS**: Any table without RLS enabled is fully exposed via the public API.

2. **Service Role Key Exposure**: The service_role key bypasses all RLS and grants admin access.

3. **Permissive RLS Policies**: Policies that allow more access than intended (e.g., any authenticated user).

4. **Unprotected RPC Functions**: Database functions callable without authentication.

5. **Storage Bucket Exposure**: Storage buckets without policies allow public read/write.

**Supabase-Specific Risk**: Supabase apps typically ship with the public Supabase anon key embedded in frontend code. That is by design — but only works safely if Row Level Security is enabled on every table. Attackers routinely query Supabase endpoints directly using the anon key from your bundle. A single table without RLS is a full data leak.

Real-world example

This is the #1 vulnerability in Supabase apps, affecting majority of vibe-coded projects.

How these issues get discovered

This isn't targeted — automated scanners run across the entire internet looking for known patterns, and Supabase apps surface like everything else. Supabase URLs follow a predictable pattern (`*.supabase.co`), making Supabase apps easy to fingerprint. Once identified, the scanner probes the specific vulnerability classes listed above.

What a security scan of a Supabase app looks at

• **RLS Policies** — Tests your Row Level Security by attempting to read/write data as anonymous and authenticated users.
• **Service Key Exposure** — Scans for service_role keys that should never be in client-side code.
• **RPC Functions** — Tests your database functions for proper authentication requirements.
• **Auth Configuration** — Checks authentication settings for weak passwords, missing verification, and rate limiting.