Can Supabase apps be hacked?

Public keys are expected. Private data should stay private.

An anon or publishable key is not a secret. Table grants and RLS policies control what clients can access. A service_role or secret key must stay server-side. A successful request alone does not prove that a row could be changed or deleted.

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

• **Database Access** — Checks discovered tables for data accessible to public clients. Read results do not establish whether inserts, updates or deletes are allowed.
• **Service Key Exposure** — Scans for service_role keys that should never be in client-side code.
• **Storage and API Exposure** — Checks discovered storage and API surfaces for observable exposure. Coverage depends on what the deployed app reveals and the enabled tests.
• **Auth Configuration** — Checks observable auth behavior, with supported authenticated checks when you supply a test login. This is not a full review of dashboard settings.