Security Scanning
Automated security scanning and RLS auditing for your Supabase projects.
Supascale includes a comprehensive security scanning system that automatically audits your Supabase projects for common security issues, focusing on Row Level Security (RLS) policies and storage configuration.
Scan Types
Audit Scans
Audit scans detect security vulnerabilities in your RLS configuration:
| Finding | Severity | Description |
|---|---|---|
| Tables without RLS | Critical | Tables with RLS disabled are accessible to anyone with the anon key |
| RLS enabled, no policies | High | Tables with RLS enabled but no policies block all access |
| Overly permissive policies | Medium | Policies using true as condition allow unrestricted access |
Coverage Scans
Coverage scans provide an overview of your RLS implementation:
- Coverage percentage: What percentage of tables have RLS enabled
- Table inventory: List of all tables with their RLS status
- Policy enumeration: All policies per table with their commands (SELECT, INSERT, UPDATE, DELETE)
Storage Scans
Storage scans audit your Supabase Storage security:
- Public buckets: Identifies buckets accessible without authentication
- Storage RLS: Checks for RLS policies on the
storage.objectstable - Policy review: Lists all storage-related policies
Running Scans
Manual Scans
- Navigate to your project's Security dashboard
- Select the scan type (Audit, Coverage, or Storage)
- Click Run Scan
- Review the results
Scheduled Scans
Configure automatic daily scans:
- Go to Settings > Security
- Enable Scheduled Scans
- Configure:
- Scan Time: When to run daily scans
- Scan Types: Which scans to run
- Minimum Severity: Threshold for notifications
- Save settings
Understanding Results
Audit Results
Each finding includes:
- Table name: The affected table
- Severity: Critical, High, or Medium
- Issue: Description of the problem
- Recommendation: Suggested fix
Example finding:
Table: user_profiles Severity: Critical Issue: RLS is not enabled Recommendation: Enable RLS and add appropriate policies
Coverage Results
The coverage report shows:
Overall Coverage: 85% Tables with RLS: - users (3 policies) - posts (4 policies) - comments (2 policies) Tables without RLS: - audit_logs - system_settings
Storage Results
The storage report lists:
Public Buckets: 1 (avatars) Private Buckets: 2 (documents, backups) Storage Policies: - Allow authenticated uploads - Allow public avatar reads
Snapshots
Supascale can track changes to your security configuration over time:
Taking Snapshots
- Run a security scan
- Click Save Snapshot
- Enter a description (e.g., "Before migration")
Comparing Snapshots
- Go to Security > Snapshots
- Select two snapshots to compare
- Review changes:
- Added policies: New policies since last snapshot
- Removed policies: Policies that were deleted
- Modified policies: Policies with changed conditions
Notifications
Configure alerts for security issues:
- Go to Settings > Security
- Enable Email Notifications
- Set Minimum Severity for alerts
- Add notification email addresses
You'll receive alerts when:
- Scheduled scans find issues above the severity threshold
- Critical security changes are detected
Remediation
Enabling RLS
-- Enable RLS on a table ALTER TABLE your_table ENABLE ROW LEVEL SECURITY; -- Force RLS for table owner too ALTER TABLE your_table FORCE ROW LEVEL SECURITY;
Creating Basic Policies
-- Allow users to read their own data CREATE POLICY "Users can read own data" ON your_table FOR SELECT USING (auth.uid() = user_id); -- Allow users to insert their own data CREATE POLICY "Users can insert own data" ON your_table FOR INSERT WITH CHECK (auth.uid() = user_id);
Fixing Overly Permissive Policies
Replace policies using true:
-- Before (too permissive) CREATE POLICY "Anyone can read" ON posts FOR SELECT USING (true); -- After (properly scoped) CREATE POLICY "Anyone can read published posts" ON posts FOR SELECT USING (published = true);
Best Practices
- Run scans regularly: Schedule daily or weekly scans
- Address critical findings immediately: Tables without RLS are a security risk
- Review new tables: Always enable RLS when creating tables
- Use snapshots: Track security configuration changes over time
- Test policies: Verify policies work as expected before deploying