Vibe-Coded App to Secure SaaS: The 4-Phase Migration [2026]

Migrating a vibe-coded prototype to a secure SaaS takes four phases: audit the breach surface, triage what to rewrite versus patch, harden identity, data, payments, and inputs against production attack patterns, and verify the controls hold before launch. The whole loop runs in two to four weeks for a typical Lovable, Bolt, or v0 prototype. Skip a phase and you ship the next Moltbook, the AI-built app that exposed 1.5 million API tokens within three days of launch [5].

The reason a migration is necessary, and not just a polish, is structural. Lovable generates Vite + React projects, not Next.js [1]. Bolt and Replit Agent ship similar defaults. Cursor produces what you prompt for, which is fast but usually misses the architectural backstop. The output runs and looks fine, but the same five mistakes show up across audited apps: missing RLS, NEXT_PUBLIC keys for service-role credentials, no input validation, no webhook signature verification, and identity reads from request bodies instead of sessions [3]. A polish doesn't move you off that pattern. A migration does.

TL;DR:

• The 4 phases: audit (Day 1), triage (Day 2), harden (Week 1 to 3), verify (half a day).
• The angle: each phase is bounded by a documented 2026 breach class. None of the work is speculative.
• The stack reality: Lovable, Bolt, and Replit Agent generate Vite + React, not Next.js [1]. Migration is often a framework move, not a refactor.
• The escape hatch: if you have not shipped yet, starting from a hardened template skips Phase 3 entirely. The trade-off is locked architecture for skipped weeks of work.
• The companion: the Vibe Coding Security guide covers the breach pattern. This post is what you run after reading it.

Table of contents

• Why does a vibe-coded prototype need a migration, not a polish?
• Phase 1: How do you audit a vibe-coded prototype in one day?
• Phase 2: How do you triage rewrite vs. patch vs. start over?
• Phase 3: How do you harden identity, data, payments, and inputs?
• Phase 4: How do you verify the controls before launch?
• What if you haven't shipped a prototype yet?

Why does a vibe-coded prototype need a migration, not a polish?

A vibe-coded prototype is a draft. AI tools optimize for the demo: a working flow, a clickable UI, a database that returns rows. They do not optimize for the production attack surface. That gap shows up the moment your prototype gets traffic.

The January 2026 Cybersecurity Insight Report scanned 20,052 indie launch URLs and found 2,217 domains exposing Supabase credentials in their frontend code, plus 2,325 critical exposures involving leaked service_role keys or tables without RLS [3]. That's roughly one in nine indie launches shipping with a credential leak. The Hacktron AI disclosure of CVE-2025-48757 was a single instance of the same pattern: 170+ Lovable apps with their databases wide open, accessible via a single curl command using the anon key visible in browser source [2]. Moltbook hit the same wall on January 28, 2026: a Supabase URL and key in client-side JavaScript, no RLS enabled, 1.5 million authentication tokens exposed within three days of launch [5].

These were not unsophisticated attacks. They were inevitable consequences of shipping code that prioritizes the demo. The architecture that makes vibe coding fast (client-side database queries, public Supabase keys, no validation layer) is the same architecture that fails in production. A polish doesn't move you off that pattern because the pattern is in the defaults the AI generates.

So the migration replaces three things:

• The data access pattern. Browser-to-database becomes browser-to-Server-Action-to-database. This is what the backend-only data access guide covers in depth, and it's the single architectural change that prevents the breach class above.
• The trust boundary. Identity, authorization, and validation move from "the AI hopes the client behaves" to "the server verifies every assumption."
• The framework, often. Lovable generates Vite + React [1]. If your production target is Next.js (the App Router, Server Actions, route handlers), the migration is a framework move plus a security rebuild, not a refactor.

The four phases below run in order because each one assumes the previous holds. Audit before triage. Triage before harden. Harden before verify. The audit is what tells you which path you're on. The harden phase is where most of the actual code changes. The verify phase is the launch gate.

Phase 1: How do you audit a vibe-coded prototype in one day?

The goal of Phase 1 is a list. Every breach instance, every file, every line. You're not fixing anything yet. You're inventorying the problem so triage can be informed. A vibe-coded prototype with five tables, a Stripe checkout, and a Lovable-generated auth flow audits in about six hours if you know what to look for.

The audit covers five categories. Each one maps to a documented 2026 breach class. The vibe coding security checklist walks the full framework; the run below is the migration-focused short version.

Audit category 1: Database access posture. List every Supabase table. For each, check whether RLS is enabled and what policies exist:

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';

SELECT schemaname, tablename, policyname, roles, cmd
FROM pg_policies
WHERE schemaname = 'public';

Any row with rowsecurity = false is publicly queryable via the anon key. Any policy granting access to the anon role is a place where drift can introduce a leak. Both go on the list. The why 170+ vibe-coded apps got hacked breakdown walks the exact mechanism attackers used against Lovable apps.

Audit category 2: Browser-exposed secrets. Search your environment files and code for NEXT_PUBLIC_ (or VITE_ if you're on the Vite/React stack Lovable generates) prefixes on anything that shouldn't be in a browser bundle:

grep -rn "NEXT_PUBLIC_\|VITE_" .env .env.local src/ app/

# Variables that are SAFE in a bundle: Supabase project URL, anon key.
# Variables that are FATAL: service_role key, Stripe secret, webhook secret,
# any third-party API key (Resend, OpenAI, Anthropic, etc.).

For every fatal hit, the credential has been live in your bundle. It must be rotated, not just removed. You cannot un-leak a key that was in production. The exposed API keys guide walks the rotation process for the common offenders.

Audit category 3: Input validation. Every endpoint that accepts data (Server Actions, API routes, edge functions) needs to be on the list of "validates with a schema" or "trusts whatever the client sent." Grep for validation libraries:

grep -rn "z\.object\|safeParse\|yup\|joi" actions/ app/api/ src/

# Compare against the actual count of mutating endpoints.

If you find 12 Server Actions and 3 calls to safeParse, you have nine unvalidated endpoints. They all go on the list.

Audit category 4: Payment surface. If you have Stripe (or any payment processor), your webhook handler needs signature verification. Grep for it:

grep -rn "constructEvent\|verifyHeader\|webhook" app/api/ src/

# An unsigned webhook handler is a critical issue. Anyone with curl can
# fake a "checkout.session.completed" event and mark themselves paid.

If constructEvent does not appear in your webhook handler, attackers can mark themselves paid. List the endpoint, list every action it triggers, and put it at the top of the harden phase.

Audit category 5: Identity reads. Find every place your code reads user.id or equivalent. The unsafe pattern is reading it from request input (form data, query parameters, URL). The safe pattern is reading it from a server-verified session:

grep -rn "userId\|user\.id" actions/ app/api/ src/

# For each hit, classify:
#   PASSES: const { data: { user } } = await supabase.auth.getUser()
#   FAILS:  const userId = formData.get('userId')

Every "fails" instance is an Insecure Direct Object Reference waiting to happen.

Output of Phase 1: a spreadsheet (or text file, the form doesn't matter) with five columns: category, file, line, severity, fix. Severity is critical, high, or medium. Critical means a breach is exploitable today. High means it's exploitable after one more mistake. Medium means it's defense-in-depth. The SaaS Security Checklist tool covers the same audit interactively if you'd rather click through than grep.

A typical Lovable prototype produces roughly 30 to 80 line items in this spreadsheet. That feels like a lot, but most are repetitions of the same three or four patterns. Phase 2 turns the list into a plan.

Phase 2: How do you triage rewrite vs. patch vs. start over?

Triage is one question, asked once for each line in your Phase 1 spreadsheet: is this fixable in place, or does the surrounding architecture need to change?

The honest answer is that "fixable in place" depends on three things: the size of the prototype, whether you have paying users, and whether the framework matches your production target. The decision rule is:

Condition	Recommendation
Under 5 tables, no payments, no users yet	Patch in place. Fix the line items, ship.
5+ tables, has payments, no users yet, Vite stack	Restart from a Next.js + Supabase + Stripe template. Faster than rewriting.
Any size, has paying users, Vite stack	Phased migration. Build the new stack alongside, cut over behind a feature flag.
Any size, has paying users, already Next.js	In-place harden. Phase 3 only, skip the framework move.
Architecture is "just RLS missing" everywhere	In-place fix. Phase 3 reduces to one category.

The trap to avoid is "half-patching." This is the mode where you fix three Server Actions to use Zod, leave seven unvalidated because they "feel simple," enable RLS on one table, and ship. The first thing an attacker tests is the seven you left, not the three you fixed. Either commit to the full harden phase or commit to a template restart. Don't do both halfway.

The other thing triage exposes is patterns versus instances. If 12 of your 30 line items are "Server Action does not validate input," that's one pattern (no Zod), not 12 problems. Phase 3 fixes the pattern once and applies the fix everywhere, which is much faster than treating each as a separate bug.

A note on the Vite-to-Next.js framework move: it sounds like a large rewrite, but for a typical Lovable prototype the visible UI (components, pages, styling) ports nearly one-to-one. What actually changes is the routing layer, the data fetching pattern (Server Components and Server Actions replace client-side hooks), and the build configuration. Most of the migration work is in the security architecture, not the framework, which is why this guide's phases are organized that way.

Output of Phase 2: a one-page plan with a chosen path (patch, restart, or phased migration) and a categorized list of fix patterns, ordered by severity. Critical items go first in Phase 3. Defense-in-depth items go last.

Phase 3: How do you harden identity, data, payments, and inputs?

Phase 3 is the work. Roughly two to three weeks for a typical prototype. The order matters because each layer assumes the previous one holds. Identity first, because authorization is meaningless if identity is wrong. Data second, because validation is meaningless if the database is publicly readable. Payments third, because money flows assume the data layer holds. Inputs fourth, because validation is the trust boundary at the entry point. Perimeter last, because headers and secrets defend against the rest, not against themselves.

Harden identity: server-verified sessions, no trust in request bodies

The pattern shift: every privileged operation reads identity from a server-validated Supabase session, never from a request body or query parameter. The cookie session is verified against Supabase's JWT signing key on every request that touches user data. The pattern const userId = formData.get('userId') never appears in any code path that does authorization.

The before-and-after of a typical vibe-coded Server Action:

// BEFORE (Lovable-generated pattern, IDOR risk)
export async function updateProfile(formData: FormData) {
  const userId = formData.get('userId') as string  // attacker controls this
  const bio = formData.get('bio') as string

  await supabase
    .from('profiles')
    .update({ bio })
    .eq('id', userId)  // updates whoever the attacker wants
}

// AFTER (server-verified identity)
import { z } from 'zod'
import { getUser, createAdminClient } from '@/lib/supabase/server'

const schema = z.object({ bio: z.string().max(500) })

export async function updateProfile(input: z.infer<typeof schema>) {
  const parsed = schema.safeParse(input)
  if (!parsed.success) return { error: 'Invalid input' }

  const user = await getUser()
  if (!user) return { error: 'Unauthorized' }

  const admin = createAdminClient()
  await admin
    .from('profiles')
    .update(parsed.data)
    .eq('id', user.id)  // session, not input
}

The full pattern, including the getClaims() vs getSession() distinction that matters for server-verified JWT trust in Next.js 16, is in the Supabase Auth in Next.js App Router guide.

Harden data: RLS deny-all, backend-only access

The pattern shift: every table in your public schema gets ENABLE ROW LEVEL SECURITY with zero policies for the anon and authenticated roles. The service_role bypasses RLS, so your Server Actions still work via the admin client. The browser cannot reach the database directly.

-- For every table audited in Phase 1
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.orders   ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.events   ENABLE ROW LEVEL SECURITY;
-- ... repeat for every table

-- Then verify
SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';
-- Every row must show rowsecurity = true.

If a table genuinely needs public read access (a marketing page pulling featured posts, a public profile by slug), that's one of the rare cases where a policy is appropriate. Use the RLS Policy Generator to scaffold the pattern instead of writing it by hand, and read the Supabase RLS policies that actually work guide for the patterns that hold up under attack.

The companion shift is in the application code: replace every createClient() browser query with a Server Action that uses createAdminClient(). The browser no longer holds database credentials, period. This is what the backend-only data access pattern covers in depth; it's the architectural fix that makes RLS drift inert.

Harden payments: signed webhooks, idempotency dedup

The pattern shift: your /api/webhooks/stripe route reads the raw request body, calls stripe.webhooks.constructEvent() with your endpoint secret, and rejects anything that fails signature verification. Then it dedupes by event.id against a stripe_events table with a unique constraint before processing.

import { headers } from 'next/headers'
import { stripe } from '@/lib/stripe/server'
import { createAdminClient } from '@/lib/supabase/server'

export async function POST(req: Request) {
  const rawBody = await req.text()
  const signature = (await headers()).get('stripe-signature')

  if (!signature) return new Response('Missing signature', { status: 400 })

  let event
  try {
    event = stripe.webhooks.constructEvent(
      rawBody,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    )
  } catch {
    return new Response('Invalid signature', { status: 400 })
  }

  // Idempotency: insert event ID, unique constraint catches duplicates
  const admin = createAdminClient()
  const { error: insertError } = await admin
    .from('stripe_events')
    .insert({ id: event.id, type: event.type })

  if (insertError?.code === '23505') {
    return new Response('OK', { status: 200 }) // already processed
  }

  // Now process the event safely...
}

Stripe's docs are explicit: "Use the official libraries from Stripe to verify events" [6]. The Stripe Webhook Verifier tool tests your signature setup against a known event before you flip the production key. The full implementation, including the Server Actions integration, is in the Stripe payments with Server Actions guide.

Harden inputs: Zod on every Server Action

The pattern shift: every file under actions/ (or your equivalent) defines a Zod schema and calls safeParse(input) as the first line of the action body. No untyped destructuring of input. No "we'll validate it in the database constraint." Validation happens at the entry boundary, before any database call.

The Phase 1 audit told you which actions are missing validation. For each, the pattern:

// Define the schema near the action
const createOrderSchema = z.object({
  productId: z.string().uuid(),
  quantity:  z.number().int().positive().max(100),
  metadata:  z.record(z.string()).optional(),
})

export async function createOrder(input: unknown) {
  // Validate FIRST, before any other logic
  const parsed = createOrderSchema.safeParse(input)
  if (!parsed.success) {
    return { error: 'Invalid input' }
  }

  // Now the rest of the action can trust parsed.data
  const user = await getUser()
  if (!user) return { error: 'Unauthorized' }

  // ... etc
}

Three rules for the schemas: strings get .min() and .max() bounds (an unbounded string is a 10MB POST waiting to happen); numbers get ranges (z.number().int().positive().max(1000) beats z.number()); objects are explicit about every field, no z.object({}).passthrough(). The Server Actions and Zod complete guide walks the patterns that hold up across forms and API routes. If you're converting an existing TypeScript type to a Zod schema, the JSON-to-Zod converter tool handles the scaffolding.

Harden perimeter: headers and secrets

The pattern shift: next.config.ts exports a headers() function that sets at minimum Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy on every response. Every secret in your environment files has either no prefix or one of the two safe prefixes (the Supabase project URL and anon key).

These are the cheapest items in Phase 3 because they're one-time configuration changes. The Next.js Security Headers tool generates a copy-paste config for the six headers above. The Next.js security hardening checklist covers the surrounding 11 steps that pair with headers, including the CSP nonce pattern that avoids unsafe-inline.

Phase 3 output: the audit spreadsheet from Phase 1 is now fully resolved. Every "critical" row has a "fix" entry showing the file and the new pattern. Every "high" row has been verified. The architecture is no longer Vite-style client-to-database; it's the Server-Action-mediated pattern that the breach classes can't reach. The vibe-coding defaults have been replaced.

Phase 4: How do you verify the controls before launch?

Phase 4 is verification, not new work. You wrote the code in Phase 3 knowing these checks existed, so launch day is confirming defaults, not discovering problems. This is exactly what the Secure SaaS launch checklist is built for: seven specific controls, four minutes each, around 30 minutes total. Each control maps to a documented 2026 breach class.

The compressed verification run, after the migration is in place:

#	Check	Verification	Reference
1	Server-validated auth on every action	grep -rn "user\.id|userId" actions/	Phase 3 identity
2	RLS deny-all on every table	pg_tables query in Supabase SQL editor	Phase 3 data
3	Zod on every Server Action	grep -rln "safeParse" actions/ matches file count	Phase 3 inputs
4	Stripe webhook verification + idempotency	grep -rn "constructEvent" app/api/ plus test event	Phase 3 payments
5	Security headers in next.config.ts	curl -I against staging URL	Phase 3 perimeter
6	No NEXT_PUBLIC_ (or VITE_) on any secret	grep on env files	Phase 3 perimeter
7	Error handling without leaks	grep -rn "error\.message" actions/ app/api/	Defense-in-depth

If anything fails, do not launch. Fix it. The verification phase is the gate that catches the cases where a Phase 3 pattern was applied to most of the codebase but missed one file. That one file is what gets exploited in production.

The other thing Phase 4 covers is the cutover plan. If you're doing a phased migration with paying users on the old prototype, the cutover happens behind a DNS swap or a feature flag, not a code deploy. The new stack runs alongside the old one. Data is migrated table-by-table with the new RLS policies already in place. Users keep their auth tokens because the Supabase auth schema is the same. The only thing that changes from their side is which Server Action handles their request, which is invisible.

For prototypes without users yet, Phase 4 reduces to the checklist and a deploy. For prototypes with users, it adds a few hours for the cutover orchestration.

What if you haven't shipped a prototype yet?

The honest answer is that the four phases above describe a non-trivial amount of work, and if you have not shipped anything yet, you can skip most of it by starting from an architecture that already has these patterns baked in.

The trade-off is clear: a hardened template means starting with someone else's architectural opinions (one stack, one auth pattern, one data access model). The win is that Phase 3 reduces from "two to three weeks of rewriting" to "zero." The defaults you'd otherwise spend weeks installing (RLS deny-all on every table, Zod on every Server Action, signed webhooks with idempotency, backend-only data access, security headers preconfigured, no NEXT_PUBLIC_ on any secret) ship as the starting state.

For a prototype with no traffic, restarting from a hardened foundation typically takes less time than migrating, because the prototype's UI and product logic port forward but the security architecture doesn't need to be invented. For a prototype with paying users, the phased migration in Phase 3 is the safer path, because you cannot afford a cutover error during the rebuild.

This is the architecture SecureStartKit ships with by default: every Server Action validates with Zod, every table has RLS deny-all in supabase/schema.sql, the Stripe webhook handler uses constructEvent with idempotency dedup, the headers are pre-configured, and no secret leaves the server. The site you're reading runs on it, which is the demo. If the migration plan above feels long, the pricing page is what it looks like to skip it. If your prototype already has users, run the four phases and let the architecture you build be the one your next prototype starts from.

Either way, the breach pattern the vibe-coding wave produced is consistent enough now that the fix is consistent too. Audit. Triage. Harden. Verify. The order is not negotiable, and skipping any phase is what put 2,217 indie domains on the Cybersecurity Insight Report's exposure list this year [3]. Your prototype does not have to be on the next one.