Before you launch an AI built app, check what it exposes publicly and use accounts you control to test customer access. Map the data it handles and restore a backup separately. A clean public scan does not establish whether one customer can read another's records.
You can get a convincing demo from a prompt and a builder in an afternoon. The difficult part starts when someone asks whether the app is safe to put in front of customers. A working login and a tidy dashboard do not answer that question. Neither does a scanner badge.
This checklist is for the owner of a web app built with tools such as Lovable, Replit, Bolt or Cursor. You do not need to prove which tool wrote each line. You do need a record of what you checked and what remains unknown. This is a first pass, not a complete security test. What else you need to check depends on the app and the data it holds. If you want the broader release decision, use our vibe coded app launch guide. This page deals with the security checks.
Start with the information the app handles
Write down what a user can enter, upload or view. Include names, contact details, documents, payments and business records. Then write down where each item goes, who can see it, which external services receive it and how you would delete it. If you cannot answer those questions, pause before inviting customers to add their information.
This is also the point to decide what your test accounts may contain. Use invented records in a staging environment. Do not copy a customer's real file into a test app to see whether the upload works. The ACSC's guidance on securing customer personal data recommends knowing what personal data you hold and limiting what you collect.
Check the public app before you ask anyone to sign in
Open the public URL in a private browser window. Follow the pages and files an ordinary visitor can reach. Check whether a staging page, admin route, debug message, source map or uploaded file reveals something it should not. Look at the browser's network requests and downloaded JavaScript for private credentials or internal information. OWASP's web security testing guide includes public page content and client JavaScript in its information leakage checks.
Run Vibe Scan against the public URL as one more external check. It inspects the submitted public page, up to eight scripts from the same origin, response headers and transport signals. It does not sign in or test private systems. Check the report's coverage and blocked checks before treating a quiet result as reassuring. The scan checks selected signals in the material it reached. It is not a security clearance.
If you find a real secret in a public file, remove it and revoke or rotate the credential. Deleting the text alone does not make an exposed key safe again. GitHub's leaked secret guidance is explicit on that point.
If you want another person to check the public layer, request the free public app review. A senior engineer emails a PDF within 24 calendar hours of receiving a working public URL. The account and data checks below still need separate testing.
Test access with two customer accounts
Create two ordinary test accounts with different records. Sign in as the first customer and try to open, change or delete a record belonging to the second. Repeat the checks for exports, files and API requests used by the interface. Do this only on an app and records you own or have permission to test. Avoid destructive experiments against live customer data.
The server or data service must deny the request. Hiding a button in the browser is not enough. OWASP's authorisation guidance says permissions should be checked on every request and denied by default. Ask your developer to show how those rules are enforced if you cannot inspect them yourself.
Check administrator access separately. The account that can view all customers, change settings or export data should not be an ordinary user with an extra menu item. Protect privileged accounts with multi factor authentication where the service supports it. The ACSC website security guide recommends multi factor authentication for administrator accounts.
Make login and input checks more than a happy path
Try a failed login and sign out. If the app offers password resets, test a valid and an expired reset link. Check whether the old session still works after sign out. If the app takes text, files or values such as prices and quantities, ask where the server validates them. A browser form can help users enter valid information, but it is not a security boundary. OWASP ASVS calls for validation at a trusted service layer.
If the app uses session cookies, ask your developer how it sets them and handles errors. OWASP's session guidance covers attributes such as Secure, HttpOnly and SameSite. Do not treat the presence of those attributes as proof that the whole login flow is safe.
Prove you can recover
Confirm that the app's data and configuration are backed up, then restore a backup into a safe environment. Keep the result and the date. An automated backup notification cannot show that a restore works. ACSC system management guidance calls for testing restoration of data, applications and settings.
Decide who receives alerts for failed logins, application errors and broken customer journeys. Name the person who can take the app offline or roll back a release. If nobody owns that response, you do not yet have an operating plan for a public app.
Keep an evidence record, including the gaps
You do not need a thick report to make the launch decision. Keep a short record that says what was checked, by whom, on which build and with what result.
| Check | Evidence to keep | Can a public URL settle it? |
|---|---|---|
| Public files and browser signals | URL, scan result and screenshots of any finding | Partly |
| Exposed credentials | Public asset finding, separate repository scan if available, and revocation or rotation record for any exposed active credential | Partly |
| Customer record separation | Test account results for read, change, delete and export actions | A public leak may show a failure, but cannot establish safe separation |
| Login and server validation | Test results and developer review of the relevant controls | No |
| Backup and recovery | Successful restore record and release owner | No |
This split matters. The OWASP Application Security Verification Standard describes a much broader set of technical controls than an external public review can verify. A public scan can raise a useful question. It cannot close every private one. Our Field Note on public review limits explains the evidence boundary.
Where the free 24 hour PDF fits
If your app has a working public staging or live URL, request a free public app review. A VibeZero engineer checks the unauthenticated pages and public evidence, then emails you a plain English PDF with evidence, any findings, priorities and practical next actions within 24 calendar hours of receiving a working public URL. The review also covers visible usability, accessibility, loading and search signals. You can use the PDF without buying anything else.
We do not sign in, inspect your repository, submit forms or test customer account separation in that free review. If the question is whether a customer can reach another customer's data, or whether a private control is implemented correctly, ask for a paid vibe code audit with the access and scope agreed first. The public PDF is a starting point, not a certificate that your app is safe to launch.
Questions founders ask before launch
Is a vibe coded app safe to launch if a scanner finds nothing?
That result only covers the scanner's checks and the material it reached. Test access between accounts, server side validation and recovery separately. Record what the scanner could not inspect.
Can the free review check my app behind a login?
No. The free public app review uses a URL that opens without a login or private preview token. Authenticated workflows and source code need a separately scoped review.
What should stop a public launch?
Pause if you cannot explain who can see customer records, if a private credential has been exposed and not revoked, or if important data cannot be restored. The precise launch decision depends on the app and the harm a failure could cause. A working demo does not resolve those gaps.