Vibe Coded App to Production: The Security Gap List

Three things change at once. The data becomes valuable to someone other than you. The traffic becomes unpredictable, including automated traffic that has no interest in your UI. And you lose the ability to say 'I will just fix it in the database', because now that action may touch real people's records.

Prototype habits are rational at the prototype stage: one environment, one shared key, everything visible, nothing logged. The task is to retire each habit deliberately instead of carrying it into production by default.

Most AI-built apps have exactly one environment, which means every experiment happens on live data. You need at least two: a development or staging setup with fake data, and production with real data.

Give each its own database project, its own keys and its own deploy target. The test of a proper split is simple: you can wipe the staging database and nothing a customer sees changes. Never copy real user data into staging for convenience.

The OWASP Secrets Management Cheat Sheet advises against storing secrets in source code, rotating them regularly so stolen ones work only briefly, applying least privilege, and auditing access. For a small team, that translates into a short routine.

• Store production keys only in your host's environment settings, never in the repository.
• Use a different key in each environment so a leak in development cannot touch production.
• Give each key the smallest permission that works. A key that sends email should not also read the database.
• Keep a list of every key, where it lives and who can rotate it. If you cannot list them, you cannot rotate them in an emergency.

Auth is where prototypes cut corners: a single test admin, a shared password, a role stored in the browser. Move authorization to the server and to the database. Never rely on a hidden button or a client-side flag to decide who may do something.

If your app queries a hosted database directly from the browser, the database rules are your backend. In 2025, a vulnerability class tracked as CVE-2025-48757 was reported for missing Row Level Security in Lovable-generated Supabase projects, and a researcher's public scan reportedly flagged 170 of 1,645 showcased projects, according to secondary coverage of the researcher's findings. The vendor disputes the framing, but the lesson holds: rules that are absent look identical to rules that work, until someone asks as a stranger.

Supabase's guidance is to enable RLS on every table in an exposed schema, revoke unneeded grants from client roles, grant back only what is required and write policies per operation. Then test with a logged-out request and with a second user account.

alter table public.invoices enable row level security;

revoke all on public.invoices from anon;
revoke all on public.invoices from authenticated;
grant select on public.invoices to authenticated;

create policy "Users read own invoices"
  on public.invoices for select
  to authenticated
  using (auth.uid() = user_id);

A prototype has console.log. Production needs logs you can search after something goes wrong, and someone or something that looks at them. Log authentication events, permission failures, payment events and unexpected server errors, each with a timestamp and a request ID.

Just as important is what you leave out. The OWASP Logging Cheat Sheet says access tokens, session identifiers and passwords should usually not be recorded directly. AI tools like to log whole request objects while debugging, and those objects contain exactly these values. Search your code for those debug lines before launch.

For monitoring, start with three alerts: a spike in server errors, a spike in failed logins, and the app being unreachable. Anything more can wait.

Know what your platform gives you, because it varies by plan. Supabase's documentation, for example, describes automatic daily backups for paid tiers with different retention periods and notes that on the free tier you export data yourself; it also notes that even with daily backups you could lose up to a day of data, which is what point-in-time recovery addresses. Check your own provider's current terms rather than assuming.

The test is a restore. Once, before launch, restore a backup into a scratch project and confirm the data is there. An untested backup is a hope, not a control.

NIST's SP 800-61 Revision 3 frames incident response as part of overall risk management: prepare in advance, then detect, respond and recover, and learn from it. You do not need a program. You need a page that answers who decides, what you do first, and who you tell.

1. 1Contain: revoke or rotate the affected key, disable the affected route or take the app offline if needed.
2. 2Preserve: save logs and note times before changing anything else.
3. 3Assess: work out which data and which users were reachable.
4. 4Notify: tell affected users and any regulator or payment partner your obligations require. This can carry legal duties, so consult a qualified lawyer for your jurisdiction.
5. 5Fix and record: patch the cause, add a test that would have caught it, and write down what happened.