Here's the thing nobody warns you about when you put Supabase behind a "real" backend.
My stack is React + FastAPI + Supabase Postgres. Every write goes through FastAPI. Every endpoint checks the user, the role, the ownership. I audited that backend HARD — rate limits, JWT validation, RLS, the whole thing. I was proud of it.
And none of it mattered for the two holes I actually shipped.
Because the Supabase anon key lives in the browser. It HAS to — that's how supabase-js talks to your project. Which means every logged-in user is holding a key that talks to Postgres directly. Not through my FastAPI. Around it.
That anon key is a SECOND API. And I'd spent months hardening the first one while the second one sat there, wide open, the whole time.
Hole #1 — the answers were just... readable
Quiz questions live in quiz_options, one is_correct boolean per option. My backend never sends is_correct to a student before they submit. Obviously.
But the browser doesn't have to ask my backend.
// any logged-in student, straight from the console:
const { data } = await supabase
.from('quiz_options')
.select('question_id, label, is_correct') // <- the answer key. all of it.
The RLS policy said "authenticated users can read quiz_options." Totally true for the rows. It just also handed back the column that decides the grade. The answer key. To anyone with a login and ten seconds of curiosity.
Fix: column-level REVOKE SELECT from the client role, and let the backend be the only thing that ever reads is_correct. (PR #775.)
Hole #2 — they could WRITE things they shouldn't
Same class of bug, bigger blast radius. The default Postgres grants let the client role insert/update far more than I'd realized — including a path toward forging a certificate. Nobody did it. But "nobody did it yet" is not a security model!
So I stopped patching table by table and flipped the whole thing:
-- kill the client's entire write surface, then grant back the ONE thing it needs
ALTER DEFAULT PRIVILEGES IN SCHEMA public
REVOKE INSERT, UPDATE, DELETE ON TABLES FROM authenticated;
GRANT UPDATE (/* your own profile fields */) ON public.profiles TO authenticated;
After that migration the browser can write exactly one thing: your own profile. EVERYTHING else goes through FastAPI, where the real checks live. (PR #794.)
The lesson I wish I'd had on day one
If your anon key ships to the browser — and with supabase-js, it does — then your RLS grants ARE your API. Not "a backend detail." The actual, public, internet-facing contract.
So audit them like it. Read every GRANT. For every table, ask one question: if a logged-in user typed this select (or insert) in their console, what comes back, and what changes? Default the client to read-almost-nothing, write-nothing — and earn each grant back on purpose.
Your backend auth can be flawless and still be theater, if the front door right next to it is unlocked.
Equip is open source under MIT: github.com/ArVaViT/equip. Both fixes are in main — PR #775 (the answer-key leak) and PR #794 (the write-surface lockdown).
What's the worst RLS grant you've ever found in your own project? I genuinely want to hear it.
ArVaViT
/
equip
Free, open-source LMS for Bible schools, ministries, and nonprofit educational programs. React + FastAPI + Supabase.
Equip
A free, open-source learning management system built for Bible schools church ministries, and nonprofit educational programs
Live demo · Roadmap · Contributing · Support · Changelog
Screenshots
Sign in (light)
Sign in (dark)
Account creation — student / teacher role picker
Mobile (390px)
Live at equipbible.com. Teacher and admin views (gradebook, course editor, analytics) are behind sign-in — create a free account to explore.
Why this project?
Hundreds of small Bible schools, home churches, and missionary training programs around the world still manage courses on paper, WhatsApp, or spreadsheets. Commercial LMS platforms are expensive, overkill, or require technical expertise that volunteer-run organizations simply don't have.
Equip is designed to change that:
- Free forever — MIT-licensed, no paywalls, no "premium" tiers.
- Simple to deploy — one-click Vercel deploy with a free Supabase database. No Docker, no servers to manage.
- Built for small scale — optimized for 20-100 students, not…
