Vibe Coding Security Checklist Before You Launch

A working AI-generated demo doesn't show that its security is correct. Before launch, check who can read and change each record, where your keys are stored, how payments are confirmed, what uploads are allowed, and how you'll notice abuse. Test with your own accounts at different roles, fix what fails, and spend review time where customer data and money are involved.

Key takeaways

• Sign-in proves who someone is. It doesn't decide what they're allowed to see. Most serious bugs in generated apps sit in that gap.
• Test permissions with two accounts you own. If one can open the other's records, stop and fix that before anything else.
• Private keys belong on the server. Anything in frontend code or a public environment variable should be treated as visible to everyone.
• Payment status must come from verified webhook events, and each event should be processed once.
• Builder security scans help catch common problems. They don't replace testing your app with real accounts.

What AI-generated code can and cannot guarantee

An AI builder writes code that matches your prompt and usually runs. What it can't know is your business rules: which customer owns which record, who counts as an admin, which actions should cost money. Those rules decide whether the app is safe, and they are easy to get subtly wrong in a prompt.

Some builders now scan for common problems. Lovable, for example, runs a quick scan on each publish and offers a deeper scan on request, and its security documentation says plainly that the scans don't guarantee security and recommends a professional review for apps handling sensitive data. Treat any scan as a starting list. The checks below are what confirm the result.

Authentication vs authorization

These two words get mixed up, and the difference matters more than anything else on this page.

AI builders are usually good at authentication because it is a standard feature. Authorization is specific to your app, so it is where problems hide. OWASP ranks broken access control first in its 2025 Top 10 of web application risks. Its core advice applies directly: deny by default, and enforce every check on the server where a user can't skip it.

Database row permissions and tenant isolation

Many AI-built apps let the browser talk straight to the database. That design can be safe, but only when the database itself decides which rows each user can read and write. In Supabase this is row level security: a policy on each table that filters rows by the signed-in user.

Check these points:

• Every table that holds customer data has row level security turned on, with a policy for each action the app uses: read, insert, update, and delete.
• Policies compare the row's owner to the signed-in user, rather than trusting an ID the browser sends.
• If customers belong to a company or team, the policy checks that membership, so one company can't reach another company's records.
• Server code that uses a service role or secret key, which bypasses these policies, verifies who is calling before it acts.

A policy that exists isn't the same as a policy that's correct. A rule that says "any signed-in user can read" passes a scan for missing policies and still exposes every customer to every other customer.

Secrets and environment variables

A secret is anything that grants access: payment keys, database service keys, email provider keys, AI model keys. Anything shipped to the browser is public, even if it's hard to find.

• In Vite-based apps, variables starting with VITE_ are built into the frontend and are visible to anyone. Lovable's security guidance makes the same point.
• Public keys meant for the browser, such as a Supabase anonymous or publishable key, are fine to expose only because row level security protects the data behind them.
• Private keys belong in a server-side secrets store, read only by server functions.
• If a private key was ever pasted into a prompt, committed to a repository, or placed in frontend code, rotate it. Removing it from the code doesn't remove it from history.

Payments and webhooks

The rule for payments is simple to state: trust the payment provider's server, not the browser. A customer can close the tab before the success page loads, and a success page can be opened without paying.

• Use test keys in every non-production environment, and confirm the preview can't charge real cards.
• Mark orders paid or subscriptions active only from webhook events, and check each event's signature using the provider's signing secret. Stripe documents this in its guide to verifying webhook signatures.
• Store each event ID and ignore repeats, so a retried event doesn't create two orders.
• Handle failed renewals, refunds, disputes, and cancellations, not just the first purchase.
• Use restricted keys with only the permissions the app needs.

File uploads and user input

Uploads and free-text fields are where outside content enters your app. For uploads, limit file types and sizes on the server, store files outside the web root or in private storage buckets, generate your own file names, and decide who can read each file. OWASP's file upload cheat sheet lists the full set of controls.

For text input, validate on the server as well as in the form, use the database library's parameterized queries, and escape anything shown back to other users. If your app sends user text to an AI model, assume the text may try to change the model's instructions, and keep the model's permissions narrow.

Bot abuse and rate limits

Public forms, sign-up pages, and AI features attract automated traffic. Each AI request also costs money. Add rate limits to sign-in, sign-up, password reset, contact forms, and any endpoint that calls a paid API. Add bot protection to public forms, cap how much one account can spend on AI features per day, and set billing alerts with every provider so a spike reaches you before the invoice does.

Monitoring and incident response

You need to know when something goes wrong, and you need a plan for what happens next.

• Error reporting that alerts a person, not just a log nobody reads.
• Logs for sign-ins, permission failures, payment events, and admin actions, without passwords or full card details.
• A short written plan: who gets alerted, how to take a feature offline, how to rotate keys, and how to tell affected customers.
• Backups you have restored at least once, so you know they work.

Practical tests and owner checklist

Run these tests in a test environment or with test data, using accounts you create for the purpose. They check your own app's rules and don't require any special tools.

Fix every priority 1 failure before inviting users. Priority 2 failures should be fixed before taking payments. Priority 3 items can follow soon after launch if the app doesn't yet have much traffic. The AI prototype to production guide includes a broader readiness matrix for the rest of the launch.

When to commission an audit

Your own checks catch the most common problems. Bring in an engineering review when:

• The app stores health, financial, legal, or children's information.
• You take payments or manage subscriptions.
• Customers belong to separate companies that must never see each other's data.
• A priority 1 test failed and you're not sure the fix covers every table.
• You're about to sign a customer contract that includes security terms.

A useful review tests the rules with real accounts, reads the policies and server functions, and gives you a written list of findings with fixes. For an example of that kind of work, see the e-commerce security and performance case study, which covers fixes from a 33-finding security review. If your project started in Lovable, the Lovable to production handoff checklist covers the platform-specific steps.

Frequently asked questions

Is vibe coding safe?

It can be, once the result is checked. The tools write working code quickly, but they don't know your business rules for who can see what. Apps that store customer data or take payments need permissions, secrets, and payment handling tested with real accounts before launch. A demo working is a different claim from the app being secure.

How do I test Supabase RLS?

Create two test accounts and data for each. Signed in as the second account, try to open, edit, and delete records that belong to the first, through your app's screens and its API. Every attempt should fail. Then review each table's policies and confirm they compare the row owner to the signed-in user.

What must be tested before taking payments?

Confirm that test and live keys are separate, that orders are marked paid only from verified webhook events, and that a repeated event doesn't create a second order. Then run a test purchase, a failed renewal, a refund, and a cancellation, and check that each one updates the customer's account correctly.