Service-role or secret key in frontend code
Privileged keys bypass RLS and must never be shipped to a browser, even when the client repository is private.
Supabase security checks
Check the Supabase boundary your users actually reach
BoringSec discovers Supabase configuration from the public app, distinguishes publishable client keys from privileged secrets and performs bounded read-only probes when a public project and anon key can be verified.
The scanner never treats the presence of a normal anon or publishable key as a vulnerability by itself. RLS and storage behavior are the relevant controls.
Run scans only on systems you own or are authorized to assess. Deep engines require verified authorization and may remain unavailable for a target.
report / sample findingIllustrative
Critical
Example report structure
Anonymous request can read rows from a discovered table
- Evidence
- A bounded request using the app’s public Supabase client context returned row data from a discovered table. Captured evidence is minimized and sensitive values are not reproduced here.
- What it means
- The observed anonymous read path indicates missing or overly broad Row Level Security for that table.
- Fix and verify
- Enable RLS, replace broad policies with least-privilege user or role conditions, review exposed data, rotate compromised privileged keys if any and retest.
This is an illustrative finding, not a result for your application. Live reports show the scanner, evidence state and coverage limits for the actual target.
Common risk paths
What deserves a closer look
These are risk patterns relevant to Supabase projects—not claims that every project has them. A finding appears only when a scanner returns supporting evidence.
Anonymous access to sensitive rows
A table can be enumerable or readable through the public API when RLS is disabled or a policy is too broad.
Public or enumerable storage
Bucket listing and object policy behavior can expose files that the application interface never links directly.
Honest coverage
What each scan surface can prove
URL evidence, connected source and authorized deep engines answer different questions. BoringSec keeps those sources separate and shows partial, blocked and unavailable states instead of turning an untested surface into a pass.
Read the public methodologyProject and key classification
Inspects the page and bounded same-origin scripts for a Supabase project URL and classifies supported anon, publishable, service-role and secret key formats.
Bounded table probes
When a project and public client key are available, performs read-only, capped probes and reports restricted, vulnerable, enumerable, unverified or skipped outcomes.
Storage posture
Checks bounded bucket-list behavior and records public bucket evidence without uploading, modifying or deleting customer data.
Explicit uncertainty
Failed assets, response caps, rate limits and rejected probes reduce coverage. The result becomes partial or unavailable instead of receiving a silent pass.
From observation to verification
A report built for the next action
- 01
Observe
Inspect the public response path and start eligible background engines.
- 02
Verify evidence
See what was observed, by which scanner and with what confidence.
- 03
Fix in context
Use a concrete remediation path and the Supabase RLS-relevant context.
- 04
Retest
Run a fresh assessment; monitoring can detect later regressions separately.
Questions before you scan
Is a Supabase anon key a leaked secret?
No. An anon or publishable key is designed for public clients. Security depends on Row Level Security and storage policies. BoringSec reports the key as informational unless observable access behavior creates a finding.
Does the scan modify my database?
No. Supabase checks use bounded read-only requests. They do not insert, update or delete rows and do not upload or delete storage objects.
Can a public scan prove every RLS policy is correct?
No. It can prove specific observed access paths and restrictions. Undiscovered tables, authenticated roles and business-specific ownership logic require authorized context and manual or connected review.
Is BoringSec affiliated with Supabase?
No. BoringSec is an independent security service and is not sponsored by, endorsed by or affiliated with Supabase.
Check the deployed application, then verify every fix
Start with the public URL. Add source or authenticated context only when you choose to expand coverage.
Start a security scan