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:

FindingSeverityDescription
Tables without RLSCriticalTables with RLS disabled are accessible to anyone with the anon key
RLS enabled, no policiesHighTables with RLS enabled but no policies block all access
Overly permissive policiesMediumPolicies 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.objects table
  • Policy review: Lists all storage-related policies

Running Scans

Manual Scans

  1. Navigate to your project's Security dashboard
  2. Select the scan type (Audit, Coverage, or Storage)
  3. Click Run Scan
  4. Review the results

Scheduled Scans

Configure automatic daily scans:

  1. Go to Settings > Security
  2. Enable Scheduled Scans
  3. Configure:
    • Scan Time: When to run daily scans
    • Scan Types: Which scans to run
    • Minimum Severity: Threshold for notifications
  4. 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

  1. Run a security scan
  2. Click Save Snapshot
  3. Enter a description (e.g., "Before migration")

Comparing Snapshots

  1. Go to Security > Snapshots
  2. Select two snapshots to compare
  3. 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:

  1. Go to Settings > Security
  2. Enable Email Notifications
  3. Set Minimum Severity for alerts
  4. 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

  1. Run scans regularly: Schedule daily or weekly scans
  2. Address critical findings immediately: Tables without RLS are a security risk
  3. Review new tables: Always enable RLS when creating tables
  4. Use snapshots: Track security configuration changes over time
  5. Test policies: Verify policies work as expected before deploying