Pre-Launch Security Checklist

Pre-Launch Security Checklist

Launching a BaaS-powered application to production is exciting, but skipping security checks at this stage can be catastrophic. This checklist covers everything you should verify before your first real user signs up.

1. Automated Security Scanning

Run AuditYour.app against your Supabase or Firebase project to catch the most common misconfigurations automatically. Automated scanning finds issues like:

• Open database rules (Firestore, Realtime Database, or missing RLS)
• Unrestricted API keys
• Publicly accessible storage buckets
• Exposed admin endpoints

Fix every critical and high-severity finding before launch.

2. Replace Test-Mode Configurations

Development often uses permissive settings for speed. Search your entire codebase for:

• Firestore rules with allow read, write: if true or time-limited test rules
• Supabase tables without RLS enabled
• API keys with no restrictions
• Debug flags (DEBUG=true, NODE_ENV=development)
• Test credentials and sandbox API keys that should be swapped for production keys

# Search for common debug flags and test indicators
grep -rn "DEBUG\|test_mode\|sandbox\|TODO.*security\|FIXME.*auth" src/

3. Credential Hygiene

• Rotate all API keys that were used during development.
• Verify that .env files are in .gitignore and not committed to the repository.
• Scan your Git history for accidentally committed secrets using gitleaks or trufflehog:

gitleaks detect --source . --verbose

If secrets are found in Git history, rotate the affected keys immediately. Consider using git filter-branch or BFG Repo-Cleaner to remove them from history if the repository is public.

4. Authentication Edge Cases

Test these scenarios that are frequently overlooked:

• Email enumeration: Does the sign-up or reset-password endpoint reveal whether an email is registered?
• Unverified email access: Can a user with an unverified email address access protected features?
• Session fixation: Is the session token regenerated after login?
• OAuth callback validation: Are OAuth redirect URIs strictly validated?
• Rate limiting on login: Can an attacker brute-force passwords?

5. Rate Limiting

Every public-facing endpoint needs rate limiting. For Supabase Edge Functions:

// Simple in-memory rate limiter (use Redis for production)
const rateLimiter = new Map<string, { count: number; resetAt: number }>();

function checkRateLimit(ip: string, limit: number, windowMs: number): boolean {
  const now = Date.now();
  const entry = rateLimiter.get(ip);
  if (!entry || now > entry.resetAt) {
    rateLimiter.set(ip, { count: 1, resetAt: now + windowMs });
    return true;
  }
  if (entry.count >= limit) return false;
  entry.count++;
  return true;
}

For Firebase, use App Check combined with Cloud Functions rate limiting.

6. Error Handling and Information Leakage

Production error responses must not include:

• Stack traces
• Database query details
• Internal file paths
• Framework version numbers

// WRONG: Leaks internal details
return new Response(JSON.stringify({ error: error.message, stack: error.stack }));

// CORRECT: Generic error with internal logging
console.error('Scan failed:', error);
return new Response(JSON.stringify({ error: 'An internal error occurred' }), { status: 500 });

7. HTTPS and Headers

• Verify that all endpoints enforce HTTPS. Configure HSTS headers with a long max-age.
• Set security headers: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin.
• Review CORS configuration to ensure only your application's domain is allowed.

8. Third-Party Dependencies

Run vulnerability checks on all dependencies:

npm audit
# or
npx auditjs ossi

Address critical and high-severity vulnerabilities. If a dependency has an unpatched vulnerability, evaluate alternatives or implement compensating controls.

9. Monitoring and Incident Response

Before launch, ensure you have:

• Error monitoring (Sentry, LogRocket, or equivalent)
• Authentication event logging
• Alerting for unusual patterns (mass sign-ups, failed auth spikes)
• A documented incident response plan with clear roles and communication channels
• Backup and restore procedures tested end-to-end