Supabase Security Scanner
Check what your deployed Supabase app exposes to public clients. Find accessible data, leaked service-role keys and access-control issues, with evidence and guidance for fixing them.
Enter your deployed app's URL. Review the findings, take the suggested fixes to your coding tool, and retest after making changes.
First scan free: issue counts and one finding revealed in detail. No card required.
Evidence you can act on
See what the scanner observed, the affected endpoint or file, and why it matters. Findings include remediation guidance, not just a score.
Use Export for AI to bring available findings into your coding tool. Review the changes and rescan to check the result.
What this scan cannot prove
VAS discovers Supabase details from your deployed app and tests reachable interfaces. It does not log into your Supabase dashboard, read every policy definition or prove that every table is protected. RLS review and tests with different user roles are still needed.
Review the security checklistPublic keys are expected. Private data should stay private.
An anon or publishable key is not a secret. Table grants and RLS policies control what clients can access. A service_role or secret key must stay server-side. A successful request alone does not prove that a row could be changed or deleted.
Supabase Security Considerations
Supabase makes development fast, but AI-generated code often skips security best practices:
- !Tables without Row Level Security enabled
- !RLS policies that are too permissive
- !Service role key exposed in client code
- !RPC functions callable without authentication
Where Security Breaks in Supabase Apps
Built on Supabase (Postgres + RLS), Supabase applications share a recognizable fingerprint, which means attackers and automated scanners find them the same way every time. Based on real vulnerability patterns in Supabase deployments, the breakdown is 2 critical-impact issues, 2 high-impact, and 1 medium-or-lower.
Real-world observation
This is the #1 vulnerability in Supabase apps, affecting majority of vibe-coded projects.
Tables Without RLS
Any table without RLS enabled is fully exposed via the public API.
Fix: ALTER TABLE name ENABLE ROW LEVEL SECURITY; on every table.
Service Role Key Exposure
The service_role key bypasses all RLS and grants admin access.
Fix: Never use service_role in frontend. Keep it server-side only. Rotate if exposed.
Permissive RLS Policies
Policies that allow more access than intended (e.g., any authenticated user).
Fix: Use (select auth.uid()) = user_id pattern. Test policies with different contexts.
Unprotected RPC Functions
Database functions callable without authentication.
Fix: Add auth.uid() IS NOT NULL checks at the start of all functions.
Storage Bucket Exposure
Storage buckets without policies allow public read/write.
Fix: Configure storage policies to require authentication and ownership.
What We Check
Database Access
Checks discovered tables for data accessible to public clients. Read results do not establish whether inserts, updates or deletes are allowed.
Service Key Exposure
Scans for service_role keys that should never be in client-side code.
Storage and API Exposure
Checks discovered storage and API surfaces for observable exposure. Coverage depends on what the deployed app reveals and the enabled tests.
Auth Configuration
Checks observable auth behavior, with supported authenticated checks when you supply a test login. This is not a full review of dashboard settings.
What You'll Get
Why Supabase Apps Need Security Scanning
Supabase provides a powerful PostgreSQL database with built-in authentication and real-time subscriptions. However, its security model relies on Row Level Security (RLS) policies that you must configure explicitly for each table.
Supabase project URLs and anon or publishable keys can appear in client-side code. Access depends on grants and RLS together, not key visibility alone. Enabled RLS without an applicable policy denies rows by default. Keep service_role and secret keys on the server.
VAS checks reachable tables and endpoints using the client access it discovers. Findings explain what was observed and how to investigate or fix it. A scan does not replace reviewing your SQL policies and testing intended read and write access with separate user roles.
How Supabase Security Scanning Works
Submit Your URL
Enter your Supabase application URL. Our scanner automatically detects your tech stack and configures the appropriate security checks for Supabase.
Automated Analysis
We check the reachable app for exposed secrets, browser protections, authentication issues and database access problems. A standard scan typically takes a few minutes; blocked requests or incomplete coverage are reported.
Get Actionable Results
Receive a detailed report with prioritized vulnerabilities, severity ratings, and step-by-step remediation guidance with code examples specific to Supabase.
Common Questions About Supabase Security
What does a VAS scan of a Supabase app check?
VAS checks the deployed pages, scripts and endpoints it can reach for issues including database access, service key exposure, storage and api exposure, auth configuration. The report records findings and coverage limits; it does not certify the whole app as secure.
What will I receive in the report?
Findings include severity, supporting evidence and remediation guidance. Your first scan is free, with issue counts and one finding revealed in detail. Paid report access unlocks every finding. Use Export for AI to bring available findings into your coding tool, review the proposed changes and retest.
Can a scan verify every permission and private workflow?
VAS discovers Supabase details from your deployed app and tests reachable interfaces. It does not log into your Supabase dashboard, read every policy definition or prove that every table is protected. RLS review and tests with different user roles are still needed.
Does VAS change my code or database policies?
VAS provides recommendations, not automatic fixes. Adapt any suggested policy or code change to your data model, test that permitted users still have access and that other users do not, then rescan. Read checks alone cannot confirm insert, update or delete permissions.
What should I know before scanning a production app?
Only scan apps you own or have permission to test. Scan requests can trigger firewall rules, logs and rate limits. Review enabled checks, and use staging or dedicated test accounts for sensitive workflows. Active tests, where enabled, need separate care because they can make changes.
Remediation Playbook for Supabase
Priority-ordered fixes for the specific findings we see in Supabase apps. Critical items close data-exposure gaps; high items prevent compromise; medium items reduce attack surface. Applies to apps using Supabase (Postgres + RLS), the dominant Supabase stack.
1. Tables Without RLS
Why it matters: Any table without RLS enabled is fully exposed via the public API.
How to close it: ALTER TABLE name ENABLE ROW LEVEL SECURITY; on every table.
2. Service Role Key Exposure
Why it matters: The service_role key bypasses all RLS and grants admin access.
How to close it: Never use service_role in frontend. Keep it server-side only. Rotate if exposed.
3. Permissive RLS Policies
Why it matters: Policies that allow more access than intended (e.g., any authenticated user).
How to close it: Use (select auth.uid()) = user_id pattern. Test policies with different contexts.
4. Unprotected RPC Functions
Why it matters: Database functions callable without authentication.
How to close it: Add auth.uid() IS NOT NULL checks at the start of all functions.
5. Storage Bucket Exposure
Why it matters: Storage buckets without policies allow public read/write.
How to close it: Configure storage policies to require authentication and ownership.
Verify the fixes stuck
Rescan after deploying a fix to check whether the original finding still appears. Compare the evidence and coverage with the previous report. For permissions and private workflows, also repeat the relevant tests with authorized and unauthorized test users.
Check your Supabase app
Find observable security issues in your deployed app, review the evidence and take the next steps with your coding tool.
Start with a free scan. See issue counts and one finding in detail, then decide whether you need full report access.
More on Supabase Security
Every angle of Supabase security, from the specific findings we detect to step-by-step fixes.
Supabase Security Risks
Specific risks we find in Supabase apps, with real-world examples.
Supabase Security Issues
Issues grouped by severity with detection and fix steps.
Supabase Best Practices
Remediation playbook derived from Supabase's actual failure modes.
Is Supabase Safe?
Honest assessment of Supabase's production readiness.
Supabase Security Checklist
Pre-launch checklist covering every finding class for Supabase.
How to Secure Supabase Apps
Step-by-step hardening guide for Supabase deployments.
Can Supabase Apps Be Hacked?
Attack vectors specific to Supabase and how they get exploited.
What People Say About Supabase Security
Community sentiment on Supabase security, compared with our scan data.
Supabase with your builder
The security gaps we find depend on which tool built the app in front of Supabase.