Pre-deploy security checklist: The absolute launch readiness guide for vibe-coded AI apps.

Securing a vibe-coded (AI-generated) app requires treating all AI output as untrusted input until you have verified it yourself. Immediately secure it by validating authentication and authorization on the backend, removing hardcoded API keys from your .env file, enabling Row Level Security in Supabase, and running an automated scanner before going live. AI coding tools like Cursor, Lovable, and Bolt generate working code fast — but they routinely introduce the exact vulnerabilities this checklist catches.

Key Security Steps for Vibe-Coded Apps

Validate Authentication and Authorization: Ensure all access checks happen on the backend, not the frontend. Verify Role-Based Access Control (RBAC) for every API endpoint, server action, and RPC function. Never accept "the UI only shows this to admins" as an authorization model.

Handle Secrets Safely: Never hardcode API keys or service tokens in your codebase. Use environment variables and confirm they are not committed to GitHub. Search for service_role, sk_live_, and OPENAI_API_KEY before every deploy.

Enable Row Level Security (RLS): Every user-facing Supabase table needs RLS enabled with policies validated against auth.uid(). An exposed table without RLS means any authenticated user can read every row.

Use Parameterized Queries: Prevent SQL injection by ensuring all database queries are properly parameterized. AI-generated database calls frequently skip this.

Run Automated Scanning: Use a security scanner like Ubserve to detect hardcoded API keys, missing RLS, and exposed endpoints before going live. Manual review alone misses what automated scanning catches in seconds.

Confirm server-only secrets stayed server-only

• Search for service_role, sk_live_, OPENAI_API_KEY, and internal admin tokens.
• Inspect environment variable exposure through NEXT_PUBLIC_ prefixes.
• Verify that client bundles do not reference internal endpoints protected only by obscurity.

One recurring AI-generated edge case is a helper that accidentally promotes a server secret into a client-safe constant:

export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!,
);

The hallucination is not subtle. The model often invents a NEXT_PUBLIC_ prefix because the code "needs to run everywhere."

Verify authorization at the mutation layer

Make sure every path answers the question: who is allowed to do this, and where is that enforced? Without proper authorization, a user can access data that belongs to someone else.

Check every:

• Route handlers
• Server Actions
• RPC functions
• Edge functions
• Background jobs

Do not accept "the UI only shows this to admins" as authorization.

Check RLS, storage, and data exposure

• Enable RLS on all user tables
• Validate policy conditions against auth.uid()
• Confirm private storage buckets are not set to public
• Review RPC functions for overly broad execution permissions

JWT payloads are useful, but they are not a permission model by themselves.

Review client-side hydration and debugging output

Hydration leaks are easy to miss because they look like harmless convenience during development.

Check for:

• Admin-only objects passed through serialized props
• Debug payloads rendered into hidden DOM nodes
• Config blobs exposing internal IDs or tokens
• User records sent to the browser unnecessarily

Confirm API and route behavior

• Auth routes reject malformed tokens
• Admin routes do not infer access from a UI role flag
• Write endpoints validate ownership before mutating
• Public APIs rate-limit or constrain abuse paths

Make the deploy observable

Before you ship, confirm you will know if the release fails securely:

• Auth failures are logged
• Billing errors are logged
• Permission denials are visible
• Important mutation paths emit useful identifiers

Final release decision

Do not ask "Does the app work?" Ask:

• Did any privileged value reach the client?
• Can one user access another user's data?
• Can a public route write or mutate unexpectedly?
• Can you explain your authorization model in one paragraph?

If you cannot answer those cleanly, the deploy is not ready.

Run your first scan free at ubserve.com.