supabaselisted

# Supabase RLS playbook Supabase exposes PostgreSQL directly to the browser through **PostgREST** (`/rest/v1/`), **GoTrue** auth (`/auth/v1/`), and **Storage** (`/storage/v1/`). The browser authenticates with a public **anon** JWT, and the *only* thing standing between an anonymous attacker and the database is **Row-Level Security (RLS)** policies. Misconfigured or missing RLS is the entire bug class: - **RLS disclosure** — `SELECT` on a table returns rows it shouldn't (PII, tokens, other tenants). - **RLS write abuse** — `INSERT` / `UPDATE` / `DELETE` succeeds anonymously, so you can **forge records the application trusts** (a "certificate" / verification / license / entitlement row, an admin flag, a balance, someone else's data). > Authorized targets only. Treat the database as production: read a single marker row to prove > disclosure, write ONE clearly-labelled marker row to prove write, then clean up. Never dump > whole tables of real PII, never mass-modify, never `DELETE` real rows. The PoC is "I read/wrote > one row I shouldn't be able to", not "I exfiltrated the customer base". Execution rule: substitute the real Supabase project ref, anon key, table, and marker IDs before running commands. Never write literal placeholders such as `<ref>`, `<table>`, `<col>`, or `<returned-id>` to files; if a value is unknown, discover it first or ask once. --- ## 0. Find the project URL + anon key in the frontend JS The project ref and anon key are *meant* to be public — t