Supabase Security: The Hidden Dangers of RLS and How to Audit Your API 🛡️

Supabase has solidified itself as the developer's favorite Open Source alternative to Firebase. The promise is incredible: you build a relational PostgreSQL database and magically get an instant REST API (via PostgREST) ready to be consumed by your frontend.

But exactly in this "magic" lies the danger.

The convenience of having an API that directly reflects your database schema brings a massive cyber risk if you ignore (or misconfigure) the heart of Supabase security: RLS (Row Level Security).

In this article, we'll break down how data leaks happen and how you can automate the pentesting of your application before going to production.

🛑 The Problem: The Default Trap

In traditional APIs (Node.js, Laravel, Spring), security lives in the backend. You write middlewares and controllers to block unauthorized access.

In Supabase, the logic is inverted: access control lives inside PostgreSQL. The database acts as the bouncer, evaluating RLS rules row by row.

The main issue? By default, when you create a new table, RLS is disabled. This means the table is 100% public. Anyone with access to "Inspect Element" on your site can grab your anon_key, send a simple GET request, and dump your entire database.

🐛 The 3 Most Common RLS Mistakes

Even when developers remember to enable RLS, logical flaws often leave the castle gates wide open:

1. The "Just Make It Work" Policy

Desperate to make the frontend render data, many devs create a SELECT policy with the expression true.

The result? You protected the edits, but reading is wide open. User data, emails, balances, and histories are exposed to any web scraper or bot.

2. The "Ghost Auth" Flaw

Does your API require the user to be authenticated (auth.role() = 'authenticated')? Great. But did you enable Email Confirmations in the Supabase dashboard?

If not, an attacker doesn't need to steal an account. They simply send a POST /auth/v1/signup forging a fake email and receive a valid JWT. To your RLS, they are now a "legitimate" user roaming freely through protected routes.

3. Mass Assignment (Privilege Escalation)

If your users table allows UPDATE (PATCH) requests for the profile owner, what prevents a malicious user from intercepting the request and injecting an extra column into the JSON payload?

{

  "name": "Hacker",

  "is_admin": true,

  "role": "superuser"

}

If your policies don't restrict which columns can be modified, a standard user becomes an admin with a single HTTP request.

🛠️ How to audit your own API?

Testing this manually is painful. It requires capturing keys, forging JWTs, opening Postman, crafting payloads, and testing method by method. Not to mention the risk of running a DELETE test and accidentally wiping out production data.

This is where DAST (Dynamic Application Security Testing) tools come in. The most direct and specialized solution for this ecosystem today is SupaSec.

Meet SupaSec

SupaSec acts as a pentest framework strictly focused on PostgREST quirks. You just input your web app's URL, and it does the dirty work:

• 
  Automated Reconnaissance: It scans your frontend JavaScript bundles, extracts your Supabase URL and public anon_key, and discovers hidden tables.


• 
  Ghost Auth Exploitation: The tool automatically tests if your API allows the creation of unconfirmed users to bypass anonymous RLS rules.


• 
  Data Dumper: Tests the resilience of your SELECT policies by trying to extract records, bypassing pagination limits.


• 
  Safe Exploit Mode (Dry-Run): This is a killer feature. You can manually test malicious PATCH or DELETE requests directly from the UI safely. SupaSec injects a native Supabase HTTP header (Prefer: tx=rollback, return=representation). This instructs the API to receive your malicious payload, evaluate the RLS rules, return the success/failure result, and then rollback the database transaction in milliseconds—leaving 0 traces and altering exactly zero bytes of production data.

✅ Security Checklist (Do It Today)

Don't wait for a data breach to review your architecture. Open your Supabase dashboard right now:

1. 
   Enable RLS on absolutely all tables (Authentication > Policies).


2. Go to Authentication > Providers > Email and toggle Confirm email.


3. Always use auth.uid() = user_id in your rules; never trust IDs passed via the JSON body.


4. Scan your application with SupaSec to ensure no sensitive data is leaking on your API's public layer.

Remember: In Serverless and BaaS architectures, frontend convenience dictates the pace, but proper database configuration ensures the developer sleeps soundly at night.