LaunchGuard
$launchguard/security-checklist

The security checklist
every AI-built app needs.

Supabase, Lovable, Bolt.new, Cursor, Claude Code — each tool generates different blind spots. This is the complete checklist before you go live.

SupabaseLovableBolt.newCursorClaude Code

UNIVERSAL CHECKS

Applies to every AI-built app

13 checks

These checks apply regardless of which AI tool built your app or which backend you use. Fail any one of these and your users’ data is at risk.

Database
RLS enabled on every table — not just toggled on, but with actual policies attached
No service_role key in client-side code, environment variables, or client bundles
Anon key permissions scoped to only what unauthenticated users should access
API
No unauthenticated endpoints that return user data or internal state
Rate limiting configured on all public-facing endpoints
CORS restricted to your actual domains — not wildcard (*)
Storage
No publicly listable buckets containing user uploads or sensitive files
Upload size limits enforced to prevent abuse
Auth
Email confirmation required before granting access
Password policies enforced (minimum length, complexity)
OAuth redirect URIs locked to your production domain only
Secrets
No API keys visible in client JavaScript bundles (check source maps too)
Environment variables not leaked via server-side rendering or error pages

SUPABASE-SPECIFIC

The most common backend for AI-built apps

11 checks

Supabase is the default backend for most AI coding tools. RLS is the single most important security boundary — and the most frequently misconfigured.

Row Level Security
Every table has RLS enabled AND has at least one policy — enabled without policies means full deny, but verify this is intentional
Test each policy as the anon role (logged out) AND as an authenticated user
Policies use auth.uid() correctly — not hardcoded user IDs or missing checks
INSERT policies validate that users can only create rows for themselves
UPDATE/DELETE policies prevent users from modifying other users’ data
Edge Functions & RPCs
Edge functions require authentication — check for Authorization header validation
RPC functions use SECURITY DEFINER carefully, or have explicit auth.uid() checks
No RPC exposes admin-level operations to regular authenticated users
Storage & Realtime
Storage bucket policies restrict uploads and reads by authenticated user
Realtime subscriptions are filtered by RLS — not broadcasting all rows to all users
Realtime is not enabled on tables with sensitive data unless RLS is verified

LOVABLE-SPECIFIC

18,000+ users exposed in real breaches

6 checks

Lovable auto-generates Supabase projects for you. The convenience is the risk: RLS policies are often missing by default, and the generated code assumes you’ll add security later. Most people don’t.

Critical Lovable Checks
Review every generated migration file — Lovable often creates tables without RLS policies
Check the Supabase dashboard directly, not just the Lovable UI, for RLS status
Lovable’s “Make Public” exposes your Supabase URL — verify policies before sharing
Test with the anon key directly via curl or Postman, not just through the Lovable app
Check for tables Lovable created for its own state that may contain user data
Verify that Lovable’s generated auth flow actually enforces email confirmation

BOLT.NEW-SPECIFIC

Full-stack generation with hidden gaps

5 checks

Bolt.new generates complete full-stack apps with API routes, database schemas, and deployment configs. The generated code often works perfectly — but auth middleware and environment isolation can have blind spots.

Critical Bolt Checks
Audit every generated API route for auth middleware — Bolt may skip it on some endpoints
Check that environment variables are not bundled into client-side JavaScript
Preview and staging deployments may expose debug endpoints or verbose error messages
Verify generated database queries use parameterized inputs, not string concatenation
Check for admin or seed routes that were generated for development but left accessible

CURSOR / CLAUDE CODE

AI-assisted, developer-owned

5 checks

With Cursor and Claude Code, you have more control — but AI-generated security policies can have subtle edge cases that pass code review at a glance.

AI-Generated Code Checks
AI-generated RLS policies often look correct but fail on edge cases — test DELETE and UPDATE, not just SELECT
Ask your AI to generate test queries that try to bypass each RLS policy
Review AI-generated auth middleware for short-circuit logic or missing token validation
Check that AI didn’t add overly permissive CORS or disable security headers for convenience
Use LaunchGuard’s Claude Code skill to run automated external verification against your live app

The one-minute alternative

Checklists work if you go through every item. But most people skip steps, miss edge cases, or don't know how to test RLS from the outside.

LaunchGuard runs every check on this list automatically — from the outside, the way an attacker would. It takes about 60 seconds and doesn't require signup.

$ launchguard scan myapp.com

Or skip the checklist entirely

Free. No signup. Tests everything on this checklist from the outside.

Scan your app
weblaunchguard.dev
cliClaude Code → /launchguard