SaaS backend: two critical holes closed, and the one that reopened
A proposals-management SaaS on Supabase was exposing user emails through a view over the authentication table, and its functions were executable by anyone holding the public key. Sensirel closed both, probed all 44 tables and 26 functions from the outside, and caught the same hole reopening seventeen days later.
44
Tables probed
0 rows returned with the public key
26
Functions probed
Execution locked down
2
Critical findings closed
Plus 1 regression caught 17 days later
0
Rows leaked
Every table, probed from outside
Executive summary
A proposals-management SaaS on Supabase was growing fast, and its database had two critical exposures: a view over the authentication table that let anyone with the public key read user emails, and functions executable by everyone. We closed both, probed every table from the outside, and caught the same hole reopening seventeen days later.
The challenge
Supabase ships with a public key that any visitor can extract from the front end. Whatever that key can read, the internet can read. Here it could read a profiles view built over the authentication users table, emails included.
The defaults are hostile. New database objects are granted to the anonymous role automatically, functions are executable by everyone unless revoked, and views run with the rights of their creator unless told otherwise. Every new feature was a new chance to leak.
There was no direct database connection, only the dashboard's SQL editor. Every change had to be a migration file applied by hand, and verified from outside.
What we built
Two migrations for the two critical findings
The profiles view was rebuilt over public tables only, with invoker rights, anonymous access revoked and authenticated users granted read. The helper functions got a pinned search path and had execute revoked from everyone, not just from the anonymous role, because the default grant goes wider than that.
An external probe, not a dashboard checkmark
Every table and every RPC function called over the REST API with the real public key, exactly as an attacker would. 44 tables, 26 functions, and then the row-level policies exercised with an impersonated logged-in user to make sure legitimate access still worked.
The regression, caught
Seventeen days later the two critical findings were back. Someone had recreated the profiles view in the dashboard to add three columns, without the invoker flag and without re-revoking. Anonymous could read emails again. A third migration fixed it the same day and the probe was re-run.
The stack
Supabase Postgres with row-level security, migrations as SQL files in the repository, probing from a script with the public key. Claude Code drafted the migrations and the probe; a person applied them in the dashboard.
Results
44 tables and 26 functions probed with the public key: 0 rows returned, every table.
2 critical findings closed, 1 regression closed within the day it was found.
The remaining advisor warnings were triaged one by one and documented as intentional, so the next person does not chase them again.
What we learned
- Supabase grants are hostile by default. Opt out explicitly every time you create an object, or it is public.
- Revoke from everyone, not from the anonymous role. The default grant is broader than the role you think about.
- A fix is not done until you have probed it from outside with the real key.
- Anything editable in a dashboard will be edited in the dashboard. Re-probe on a schedule, not once.
How it works
Probe with the public key
Every table, every function, as a stranger would.
Fix by migration
Invoker rights, revoked grants, pinned search paths.
Verify both ways
Anonymous gets nothing, a logged-in user still gets their rows.
Re-probe later
Because someone will recreate the view.
See what your team
can hand to AI
A free 30-minute call. We map one workflow together and you leave with a plan you can use, with or without us.
Book a Free Strategy Call