Ship safely on Supabase — the RLS, secrets, and auth checks built in
Supabase is the fastest backend for AI-built apps. It's also where the most catastrophic bugs land — RLS misconfigurations, leaked service-role keys, broken JWTs. Securie's Day-1 specialists are tuned exactly for this stack.
This is for you if…
- Building a Supabase-backed app — Auth + Postgres + Storage + maybe Edge Functions
- Using `auth.uid()` in your RLS policies and hoping you wrote them right
- Storing your service-role key in Vercel env vars and hoping it never leaks
- Worried that some table somewhere is missing RLS
The moments you feel this
You wrote 12 tables. You added RLS to 'most of them.' You can't remember which ones you skipped. The Supabase dashboard's Policy view is hard to read at scale. You keep meaning to audit; you keep not getting around to it.
You ran `git log -p -S 'eyJ' | head` last week and saw a JWT in an old commit. You can't tell from the dashboard if it was the anon key or the service-role key. You're not sure if you should rotate.
You added a Supabase Storage bucket for user uploads. You assumed it was private by default. It wasn't. Every upload's URL is publicly guessable. You only find out when a user emails asking why they can see other users' files.
Someone publishes a third-party audit of N Supabase projects in the wild and finds a double-digit percentage with critical RLS holes. You wonder if you're in the sample.
What Securie does for you
Day-1 production-validated Supabase RLS specialist
Securie reads every CREATE POLICY statement in your migrations + every Supabase client call in your code, sandbox-replays the exact attacks (cross-user SELECT, cross-user INSERT, anon-role grant abuse, USING-without-WITH-CHECK), and ships findings only when the attack succeeds.
Service-role key detection + auto-rotation
Securie's secret_scanner detects Supabase JWT patterns + decodes the role claim. If the role is service_role and the file is reachable from a client bundle, the finding ships with 'Live key confirmed' + (Indie tier and up) an auto-rotation PR that resets the key in Supabase, updates env vars, and revokes the old key.
Storage bucket public-by-default audit
Securie reads your Supabase project's storage bucket configuration via the Supabase Management API + flags any bucket marked public when the linked code path serves user-specific data. The fix: convert to private + use signed URLs for downloads.
JWT secret + auth metadata audit
Securie verifies that the anon role does NOT have read access to auth.jwt_secret or related metadata (the canonical Supabase misconfig that lets anonymous clients forge JWTs). Findings ship with the exact GRANT/REVOKE statement to fix it.
What you don't need to know
- — How to write QL queries against your Postgres schema
- — How RLS internals work at the Postgres-policy-engine level
- — How to manually decode JWTs to check role claims
- — How to write a Supabase admin REST script to audit your storage buckets
What you actually do
- Install the GitHub App (one click)
- Connect your Supabase project (one click via Supabase OAuth)
- Open a PR that touches a migration file or a Supabase client call
- Read the findings inline in the PR — each comes with the reproduced exploit + the fix
“Supabase RLS misconfiguration is the #1 finding category across vibe-coded apps audited in 2025-2026. Day-1 specialist coverage exists exactly because the incident frequency justified it.”
But wait…
Doesn't Supabase already have built-in security?
Supabase's RLS engine + Auth service are well-built — they enforce what you tell them to enforce. The bug surface is what you tell them — the policies you write, the role grants you set, the JWT secret you may accidentally expose. Securie audits the policies + grants + secret-exposure surface; Supabase enforces them once you've written them right.
We're a tiny project. Do we really need this?
Tiny Supabase projects are exactly the ones where one missed RLS policy leaks every customer's data. The Wiz public-research-disclosure finding holds — small Supabase projects with vibe-coded RLS are a meaningful share of the leak surface.
Can I run this on my Supabase project without giving Securie service-role access?
Yes — Securie reads your Supabase project's policies + storage config via the Supabase Management API (separate from the service-role key) using a bounded scope token. The service-role key never leaves your environment. Securie does NOT run any privileged action on your database.