Automated Security Scanning for BaaS Apps

Why Automated Scanning Matters

Manual security reviews are essential but insufficient for modern BaaS applications. Configurations change frequently, new tables are added, policies are modified, and new team members may not be aware of security requirements. Automated scanning catches regressions, enforces baselines, and provides continuous assurance that your security posture has not degraded.

What to Scan

Database Configuration (Supabase)

Automated scans should check:

• RLS status: Is RLS enabled on every public table?
• Policy coverage: Does every table have policies for SELECT, INSERT, UPDATE, and DELETE?
• Policy restrictiveness: Do policies reference auth.uid() or are they overly broad?
• Role permissions: What can the anon and authenticated roles access?
• Function security: Are RPC functions using SECURITY DEFINER appropriately?
• Schema exposure: Are internal tables accidentally in the public schema?

-- Query to find tables without RLS
SELECT schemaname, tablename
FROM pg_tables
WHERE schemaname = 'public'
AND tablename NOT IN (
  SELECT relname FROM pg_class
  WHERE relrowsecurity = true
);

-- Query to find tables with RLS but no policies
SELECT t.tablename
FROM pg_tables t
JOIN pg_class c ON t.tablename = c.relname
WHERE t.schemaname = 'public'
AND c.relrowsecurity = true
AND NOT EXISTS (
  SELECT 1 FROM pg_policies p
  WHERE p.tablename = t.tablename
  AND p.schemaname = 'public'
);

Security Rules (Firebase)

Automated checks should verify:

• No open rules: No allow read, write: if true at the top level
• Authentication checks: Rules require request.auth != null
• Owner validation: Write rules validate document ownership
• Data validation: Write rules validate data structure and types
• Wildcard scope: Recursive wildcards ({document=**}) are not overly broad

API Endpoint Testing

Test your exposed endpoints with different authentication states:

// Pseudocode for automated endpoint testing
const tests = [
  { name: 'Unauthenticated read', auth: null, method: 'GET', table: 'users', expectStatus: 401 },
  { name: 'Auth read own data', auth: userAToken, method: 'GET', table: 'users', filter: 'id=userA', expectStatus: 200 },
  { name: 'Auth read other data', auth: userAToken, method: 'GET', table: 'users', filter: 'id=userB', expectRows: 0 },
  { name: 'Auth write other data', auth: userAToken, method: 'PATCH', table: 'users', filter: 'id=userB', expectStatus: 403 },
];

for (const test of tests) {
  const result = await executeTest(test);
  if (result.status !== test.expectStatus) {
    reportVulnerability(test.name, result);
  }
}

Mobile Binary Analysis

Scan APK and IPA files for:

• Embedded API keys (service role keys, secret keys)
• Hardcoded URLs pointing to staging or internal environments
• Debug flags left enabled
• Certificate pinning configuration
• Insecure storage usage

Integration Points

CI/CD Pipeline

Run security scans as part of your deployment pipeline:

# GitHub Actions example
name: Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check for secrets in code
        uses: gitleaks/gitleaks-action@v2

      - name: Run BaaS security scan
        run: |
          curl -X POST https://audityour.app/api/scan \
            -H "Authorization: Bearer $\{{ secrets.AUDIT_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{"projectUrl": "$\{{ secrets.SUPABASE_URL }}", "anonKey": "$\{{ secrets.SUPABASE_ANON_KEY }}"}'

      - name: Check migration safety
        run: |
          # Verify new migrations don't disable RLS
          grep -r "DISABLE ROW LEVEL SECURITY" supabase/migrations/ && exit 1 || true

Scheduled Scans

Configuration drift happens over time. Schedule regular scans:

// Using AuditYour.app's auto-scan feature
const autoScanConfig = {
  projectUrl: 'https://your-project.supabase.co',
  schedule: 'weekly',  // or 'daily', 'monthly'
  notifications: {
    email: true,
    slack: true,
    slackWebhook: 'https://hooks.slack.com/...',
  },
  alertThreshold: 'medium',  // Alert on medium severity and above
};

Pre-Deployment Checks

Before deploying database migrations, verify they do not introduce vulnerabilities:

#!/bin/bash
# pre-deploy-check.sh

# Check for tables created without RLS
if grep -l "CREATE TABLE" supabase/migrations/*.sql | while read f; do
  if ! grep -q "ENABLE ROW LEVEL SECURITY" "$f"; then
    echo "WARNING: $f creates a table without enabling RLS"
    exit 1
  fi
done; then
  echo "All migrations have RLS enabled"
fi

# Check for dangerous permission grants
if grep -rE "GRANT.*(ALL|SELECT|INSERT|UPDATE|DELETE).*TO (anon|public)" supabase/migrations/*.sql; then
  echo "WARNING: Migration grants broad permissions to public roles"
  exit 1
fi

Scan Result Management

Prioritization

Not all findings are equal. Prioritize by:

1. Critical: Service role key exposed, RLS disabled on tables with sensitive data, open Firebase rules
2. High: Overly permissive RLS policies, missing authentication on endpoints
3. Medium: Missing WITH CHECK clauses, broad CORS configuration
4. Low: Informational findings, non-sensitive data exposure

Remediation Workflow

1. Triage: Review findings and confirm they are real issues
2. Prioritize: Address critical and high severity first
3. Fix: Apply the remediation steps
4. Verify: Re-scan to confirm the fix
5. Monitor: Set up alerts to catch regressions

Tracking Over Time

Track your security posture over time:

• Number of open findings by severity
• Mean time to remediation
• Scan pass rate in CI/CD
• New findings per deployment

Getting Started with AuditYour.app

AuditYour.app provides automated security scanning specifically designed for Supabase and Firebase applications. Connect your project to get a comprehensive security report covering RLS, policies, permissions, storage, and API exposure. Set up scheduled scans to maintain continuous security assurance.