A public key is not the vulnerability
Supabase publishable keys and legacy anon keys are designed for public application components. Seeing one in a browser does not prove a leak. Privileged secret and service-role keys belong on the server. We distinguish expected public configuration from a credential or permission that actually grants unintended access.
Test the permissions behind the interface
Postgres grants and row-level security policies work together to control access. Within an authorized scope, we compare what an anonymous visitor, an authenticated account, and a record owner can read or change. The relevant question is whether those permissions match the application’s intended behavior—not whether a database responds at all.
Separate read access, write access and administration
A read-only exposure is different from the ability to change records or perform an administrative action. Our findings identify the affected data, required role and observed operation. We use minimal controlled evidence and approved test records where possible. One accessible table is not evidence that every database table or account is compromised.
Review the connections around the database
Where agreed, a review can include the application’s API, authentication boundaries, server-side functions and file-storage permissions. Frontend restrictions must align with backend controls. Testing your own application does not authorize testing Supabase’s shared infrastructure or another customer’s project. Project configuration or source review needs its own agreed access.
Give the fix a clear acceptance test
A useful report explains the permission that failed, business impact, evidence and remediation direction. A retest should check that the original unintended access is blocked while legitimate functionality still works. We record the tested version, roles, operations and limits so your developers know what the result establishes.
A few practical answers.
Is Supabase itself insecure?
The service name alone does not determine security. The application’s grants, policies, key handling and server-side authorization determine what a visitor can actually reach. A public application key is expected; unintended data access is the issue.
Is the initial check a full Supabase audit?
No. The initial check is a limited first look at agreed areas. A complete project review, multiple roles, configuration access, source review and retesting need a separately agreed scope.
Will you copy our production database?
Bulk extraction is not a default testing method. We agree the minimum evidence needed and use controlled test data where possible. Sensitive records stay out of public demonstrations.