Pre-Launch Checklist

Vibe Coding Security Checklist

30 security checks for your vibe-coded application. Complete the 13 critical items before launching to production.

Auto-Check with VAS Scan

VAS automatically verifies many checklist items.

Total Checks

Critical Items

Database Securitycritical

Protect your data from unauthorized access

Row Level Security (RLS) enabled on ALL Supabase tables(CRITICAL)

Run: SELECT tablename FROM pg_tables WHERE schemaname = 'public' AND NOT rowsecurity;

RLS policies created that restrict access to user's own data(CRITICAL)

Each table should have SELECT, INSERT, UPDATE, DELETE policies

Firebase Security Rules deployed (if using Firebase)(CRITICAL)

Rules should deny by default, allow only specific authenticated operations

Tested database queries without authentication return no data(CRITICAL)

Use Supabase REST API or client without session to verify

Service role key only used on server-side, never in frontend(CRITICAL)

Search codebase for 'service_role' - should only be in server files

Secrets & Credentialscritical

Keep your API keys and passwords safe

All API keys stored in environment variables, not code(CRITICAL)

Search for patterns like 'sk-', 'sk_live_', 'AIzaSy' in source files

.env files added to .gitignore(CRITICAL)

Verify .env, .env.local, .env.production are all in .gitignore

No secrets in git history(CRITICAL)

Run: git log -p | grep -i 'sk-\|password\|secret\|api_key'

Production secrets set in hosting platform, not local files

Check Vercel/Netlify/Railway dashboard for environment variables

Any previously exposed keys have been rotated(CRITICAL)

If keys were ever in git, consider them compromised and rotate

Authenticationcritical

Secure user access to your application

Authentication checked on server-side for all protected routes(CRITICAL)

Every API route should verify session before returning data

Email verification enabled for new signups

Check auth provider settings - users should confirm email before full access

Password requirements enforced (min 12 chars, complexity)

Test signup with weak passwords like '123456' - should be rejected

Session timeout configured appropriately

Default is often too long - consider 1 hour for sensitive apps

Logout properly clears session and redirects

Test that logged-out users can't access protected pages

API Securityhigh

Protect your API endpoints

All data endpoints verify user owns the requested resource(CRITICAL)

GET /api/orders/:id should check order.userId === session.user.id

Input validation on all API endpoints(CRITICAL)

Use Zod or similar to validate request body, params, query

Rate limiting configured for public endpoints

Prevent brute force attacks on login, signup, password reset

Error messages don't leak sensitive information

Return generic errors to client, log details server-side

CORS configured to allow only your domains

Check Access-Control-Allow-Origin header isn't '*' in production

Security Headershigh

Configure HTTP security headers

Strict-Transport-Security header enabled

Enforces HTTPS connections

X-Content-Type-Options: nosniff enabled

Prevents MIME type sniffing attacks

X-Frame-Options set to DENY or SAMEORIGIN

Prevents clickjacking attacks

Content-Security-Policy configured

Prevents XSS by controlling script sources

Referrer-Policy configured

Controls information sent to other sites

Code Qualitymedium

General security hygiene

Dependencies updated, no known vulnerabilities

Run: npm audit or yarn audit

No sensitive data logged to console

Search for console.log with user data, tokens, passwords

Source maps disabled in production

Check build output doesn't include .map files in public

Error boundaries prevent crash information leakage

Production errors should show generic message, not stack trace

Security scan completed with no critical findings(CRITICAL)

Run VAS scan and address all critical/high findings

Don't Check Manually—Scan Automatically

VAS automatically checks for RLS issues, exposed secrets, missing auth, security headers, and more. Get results in minutes.

Run Get Starter Scan

Frequently Asked Questions

How do I use this security checklist?

Go through each section and verify every item. Critical items (marked in red) must be completed before launch. Non-critical items should be completed but won't cause immediate security issues if delayed. Run a VAS scan to automatically verify many of these items.

What if I can't complete all items before launch?

At minimum, complete all critical items before launch. These include: RLS enabled on all tables, no secrets in code, server-side auth checks, and ownership verification on APIs. Non-critical items can be addressed post-launch but should be prioritized.

How often should I review this checklist?

Review before every production deployment, especially after adding new features or database tables. AI tools can introduce new vulnerabilities with each code generation. Make security review part of your deployment process.

Can VAS check all these items automatically?

VAS can automatically check many items including: RLS configuration, exposed API keys, missing security headers, authentication issues, and more. Run a scan to get automated verification of your security posture.

What's the most commonly missed item on this checklist?

RLS policies on Supabase tables. Developers enable RLS but forget to create the actual policies, or create tables and forget to enable RLS. This results in a completely exposed database despite thinking security is configured.

Related Security Resources

Best Practices Guide Common Vulnerabilities Security Risks Startup Security Checklist

Last updated: January 16, 2026