Vibe Coding Security: Five Checks Before You Launch

Before customers use your vibe-coded app, check five things: private keys stay private, customers cannot open each other’s records, important actions are checked behind the screen, private files stay restricted, and costly features have limits. You can run some checks yourself. Others need your AI tool or a reviewer to inspect how the app works.

This vibe coding security checklist is for entrepreneurs and consultants, including those helping clients who built their own apps. You or your client may use tools such as Lovable, Replit, Bolt, v0, or Base44. You do not need to read code to organize the review or recognize a failed check.

These checks come from real failures. In 2025, researchers scanned 1,645 apps built with Lovable and found inadequate database access rules in 170 of them, about 10.3%, across 303 exposed endpoints. The issue was recorded as CVE-2025-48757 and rated critical: unauthenticated visitors could read or write data in affected apps’ database tables. Check 2 covers the same kind of access rule.

For the wider launch plan, including backups, payments, and support, start with the production readiness checklist. If you already have a list of problems and are considering starting again, read repair or rebuild a vibe-coded app.

Start with a safe test copy

Use made-up customer records and your payment provider’s test mode. Ask your tool to confirm that the copy cannot change live records, charge real cards, or send messages to real customers. If it cannot confirm that separation, get help before testing failures.

Give each check one of four results: passed, failed, not checked, or not applicable. Keep a short note explaining the result. An unchecked safeguard is still unresolved work.

Check	What you can try	What needs technical verification
Private keys	Review where the tool says each key is stored.	Private values are absent from everything sent to the browser.
Customer records	Try two test accounts and a logged-out visit.	Requests cannot bypass the access rules.
Important actions	Enter invalid information in test forms.	The app checks prices, ownership, and permissions behind the screen.
Uploaded files	Try opening another test user’s file link.	Public links, temporary links, and file permissions match the intended sharing rules.
Paid or message-sending features	Repeat an action in a small, controlled test.	Limits apply even when someone bypasses the interface.

1. Are your private service keys kept out of the browser?

A private service key can let someone use your paid account or reach your data. Treat it like a password. The browser is the software on the customer’s device; the server is the part of the app running under your control. Private keys belong on the server.

Some keys are intended to be public. Supabase’s key guide distinguishes publishable keys from secret keys, which have much broader access. Do not rotate every public key just because you can see it.

Ask your AI tool:

Find the service keys this app uses. List their names and locations, never their values. Separate keys designed to be public from private secrets. Check whether any private value reaches a customer's browser. Explain what you inspected and what you could not inspect. Propose the fix before changing anything.

What you can verify: Ask for the findings in plain language: which private key was exposed, where it was found, and how the reviewer checked the fix. A screenshot of a “Secrets” setting alone is not proof that the value stays private.

If it fails: Replace and revoke the exposed secret through its provider, and remove the exposure. Have the replacement checked too. Do not paste the key into a chat or a review document.

2. Can one customer see or change another customer’s records?

A login page answers “Who are you?” Access rules answer “What are you allowed to do?” Both matter.

OWASP’s authorization guidance recommends denying access unless allowed and checking permissions on each request. In everyday terms, the app must check ownership when someone asks for a record, even if they never used its buttons.

Try this yourself:

1. Create two test accounts that should not share information.
2. As Customer A, create a booking or another private record.
3. Open a separate browser session as Customer B and try Customer A’s record link.
4. Try again while logged out. Also try an admin page as a regular customer.
5. Check that any sharing you actually intend, such as within one team, still works.

Pass looks like: Each person can reach only the information and actions their role allows. Ask a reviewer to verify the same restrictions behind the screen; hiding a link is not enough.

Ask your AI tool:

Write down who should be allowed to read and change each kind of record. Include customers, shared teams, admins, and people who are logged out. Test those rules both through the interface and through direct requests. Explain the result of each test, including anything you could not verify.

If you use Supabase, the term you may see is Row Level Security, or RLS. With RLS enabled and no policies, ordinary client access is blocked. Policies open the access you choose; a policy allowing everyone is a different situation from having no policy. Privileged server keys can bypass RLS, so those paths also need review. Supabase explains these distinctions. The Lovable exposure above involved exactly these rules, which is why the two-account test matters even when a scan reports that RLS is on.

3. Can someone change prices or permissions from the screen?

Imagine a checkout that accepts whatever price the customer’s browser sends. A person who changes that request could pay a different amount. The app needs its own trusted record of the price and the buyer’s permissions.

Try this yourself: Submit missing fields, impossible dates, and information that does not fit the form. The app should explain the problem and avoid saving an invalid result.

Ask your AI tool or reviewer:

In the test copy, check whether someone can change a price, their role, or a record's owner by altering a request. Show that the server calculates or checks those values using trusted records. Also test requests that skip the form's checks. Do not use live transactions.

Pass looks like: Invalid or unauthorized actions fail before changing anything. A displayed warning is useful, but the protection must also work on the server. That is why OWASP recommends server-side input checks.

You do not need to learn how to alter a request yourself. Ask the reviewer to demonstrate the attempt and its rejected result.

4. Check who can open uploaded files

Your customer records and uploaded files may have different permissions. Protecting an invoice record does not automatically protect the PDF attached to it.

Try this yourself: Upload a made-up private document as Customer A. Try its link as Customer B and while logged out. Write down what happens, then ask what kind of link it is.

A file opening does not by itself prove the storage is public. A signed link is a temporary pass: anyone holding it may be able to open the file until it expires. Supabase supports these links for private files. See its private-file sharing documentation.

Ask your AI tool:

Explain which files are public and which should be private. For private files, test who can request a download link, whether another customer can get one, and when any temporary link expires. Check upload and delete permissions too. Show how the results match our intended sharing rules.

Pass looks like: Public files are deliberately public. Private files follow your chosen sharing rules, including who can create temporary links and how long those links last. Unexpected access needs investigation before release.

5. Put limits on features that can run up bills

A feature that generates AI responses, sends texts, or processes images can cost money each time it runs. Decide what one customer should be able to use and what happens at the limit.

Ask your AI tool:

List the actions that spend money or send messages. Propose sensible limits for each account and time period, and a clear message when a limit is reached. Test the limits behind the interface as well as through it. Explain any provider budget controls and whether they stop spending or only send an alert.

Try this yourself: In the test copy, use a deliberately low limit and make a few requests. Confirm the next request is refused or delayed as intended. Avoid generating a large bill to test whether a large bill is possible.

Pass looks like: The app enforces the limit, tells the customer what to do next, and notifies the owner when appropriate. Check provider settings too, but do not assume every service offers a hard spending cap.

What should stop you from launching?

Keep an affected feature closed to customers if you find an exposed private key, unauthorized access to records or files, or a way to change prices or permissions. Resolve untested controls before relying on them for real customer data or paid actions.

These are five useful starting checks, not a complete security audit. A reviewer should also consider account recovery, software updates, harmful uploads, and other risks specific to what your app does.

Run your platform’s security scan if it has one. Lovable’s documentation explains what its scans cover and why they do not replace a thorough review. Keep the report, fix relevant findings, and repeat the practical checks after changes.

What should a consultant hand back to the client?

For each issue, record what was tested, what happened, what changed, and who verified the fix. Redact customer information and secrets. Mark anything unresolved instead of describing the whole app as “secure.”

Ask the client to try the two-account test with you. It gives them a concrete understanding of the protection and a check they can repeat after a major update.

Return to the launch checklist for payments, recovery, and support. If a reviewer recommends starting over, use the repair-or-rebuild guide to ask what needs replacing and why.

Talk to UX Soda about reviewing your app before launch.

Frequently asked questions about vibe coding security

Is vibe coding secure enough for real customers?

It can be, but these five checks alone do not establish that an app is secure. Start with private keys, access to customer records, server-side checks on important actions, file permissions, and usage limits. Have a reviewer assess other risks specific to the app and its customers. A successful demo or a clean platform scan is not a complete security review.

Does adding a login page protect customer data?

No. Login establishes who someone is; separate access rules decide which records, files, and actions they can reach. Test with two accounts and while logged out, and ask a reviewer to check requests that bypass the visible interface.

Does turning on Row Level Security make my data safe?

No, not on its own. In Supabase, enabling Row Level Security without policies blocks ordinary client access, and policies then allow specific operations. Overly broad policies can expose data, while privileged server keys can bypass RLS. You need the right rules and tests of who can actually read and change each record.

Is a file public if its link opens while I am logged out?

Not necessarily. It may be public or accessible through a temporary signed link; investigate how access is granted rather than assuming those are the only possibilities. A signed link can grant access to a private file until it expires. Check who can obtain access and whether any link's permissions and expiry match your intended sharing rules.

Can I check my app without being a developer?

Yes, for account separation, sharing, forms, and limits, which you can test in a safe test copy. A technical reviewer should verify hidden details such as exposed private keys and access checks behind the interface. Ask for a demonstrated test result and a plain-English explanation of anything still unverified.