A vibe-coded app is built mostly by prompting an AI tool, and it needs the same pre-launch checklist as any app, starting with access control. Log in as one user and request another user's records, test every database table for row-level security, search the shipped bundle for secrets, validate input on the server, and confirm you have logs, alerts, backups and a rollback path. Veracode's 2025 test of over 100 models found that 45 percent of code samples failed security tests, so treat generated code as untrusted until you have tested it.
The short answer
An app built by prompting an AI tool still needs the checks every app needs before real users arrive, and the order matters. Start with whether one user can reach another user's data. That means testing access control on every endpoint and row-level security on every database table, using the same keys and calls a stranger would have. Then look for secrets in the shipped code, test input handling on the server, and confirm that you will find out when something breaks, that you can restore a backup and that you can roll back a bad deploy.
You do not have to trust a headline to justify the effort. Veracode's 2025 test of more than 100 models found that 45 percent of code samples failed security tests. A CVE record describes a database rule failure in one AI app builder that exposed generated sites' tables to unauthenticated readers and writers, though the supplier disputes the record. Supabase's own docs say a table without row-level security is open to any role with a grant on it. The checks below are the ones that decide whether launch day goes well.
What the evidence says
| Source | What it says | How to read it |
|---|---|---|
| Veracode, 2025 GenAI Code Security Report (blog dated 30 July 2025) | Over 100 models tested across Java, Python, C# and JavaScript; 45 percent of code samples failed security tests and introduced OWASP Top 10 vulnerabilities. Failure rates by language were Java 72 percent, C# 45 percent, JavaScript 43 percent and Python 38 percent. Cross-site scripting was not defended in 86 percent of relevant samples. Models got better at working code but not at secure code | Veracode sells application security testing, and we read its blog, not the full report. It tests whether generated code is secure, not whether a given app is |
| NVD record for CVE-2025-48757 (published 30 May 2025) | An insufficient database row-level security policy in Lovable through 15 April 2025 allows remote unauthenticated attackers to read or write arbitrary database tables of generated sites. The record adds that the supplier disputes this, because each customer of the platform accepts responsibility for protecting its application's data | A real case of the database rule problem. Read the dispute note too: who is responsible is contested. The record carries a CVSS 3.1 base score of 9.3 out of 10 |
| Supabase documentation on row-level security | A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every such table. Views bypass RLS by default, a policy that reads to the anon role using true opens every reachable row to every visitor, and the service role bypasses RLS so it must stay server-side | Vendor guidance for one popular back end. Other back ends have equivalent rules, so find yours |
| Spracklen and others, "We Have a Package for You!" (arXiv, June 2024) | Across 16 code-generating models and 576,000 samples, the average share of hallucinated package names was at least 5.2 percent for commercial models and 21.7 percent for open-source models | An academic study from 2024. The authors call hallucinated package names a new form of package confusion attack, so check every dependency |
Ten checks before real users arrive
The Reference column uses the categories of the OWASP Top 10:2025: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, and A10 Mishandling of Exceptional Conditions.
| # | Check | The test to run | Reference |
|---|---|---|---|
| 1 | Access control on every endpoint | Create two accounts. With account A's session, request account B's records by ID on every endpoint that takes an ID, and call each endpoint with no session at all. Every request should return 401, 403 or 404 | OWASP A01 |
| 2 | Row-level security on every exposed table | Take the public anon key from the browser's network tab and call each table through the API from outside the app. Check grants, views and any policy written as using (true). Nothing private should come back | Supabase docs, CVE-2025-48757 |
| 3 | Secrets and keys | Search the built bundle, the repository and its history for API keys, database URLs and service-role keys. Revoke and replace anything that was ever committed or shipped to the browser | OWASP A02, Supabase docs |
| 4 | Server-side validation and injection | Send malformed and hostile input straight to the API, skipping the form. Confirm queries are parameterized and outputs are escaped where they are rendered | OWASP A05, Veracode |
| 5 | Authentication and sessions | Test password reset, email verification, session expiry, logout and rate limits on login, and test the failure paths as well as the happy path | OWASP A07 |
| 6 | Dependencies | List every package. Confirm each exists and is the one intended, pin versions, remove what is unused and run your package audit tool | OWASP A03, Spracklen and others |
| 7 | Logging and alerts | Trigger a failed login and a server error in staging. A person should be notified and the log should say what happened without printing secrets | OWASP A09 |
| 8 | Failure handling | Switch off the database or an external API in staging. The app should fail closed, show a plain error and leak no stack trace | OWASP A10 |
| 9 | Configuration | Debug mode off, storage buckets private by default, CORS limited to your domains, admin routes behind real authorization, security headers set | OWASP A02 |
| 10 | Backups and rollback | Restore the latest backup into a clean project and read the data back. Roll a deploy back to the previous version. Until you have tested a restore, treat the backup as unproven | Our recommendation |
If the app calls a language model, add the OWASP LLM Top 10 pre-launch tests, the vendor data terms and, for a mobile app, the App Store and Google Play rules. If you sell to consumers in the EU, read the European Accessibility Act guide and EU AI Act for AI MVP founders.
Harden it or rebuild it
Our rule of thumb, from what we look for when reading a prototype's code:
| What the checks show | Likely path |
|---|---|
| Failures in secrets, configuration, logging or backups only | Harden. These are fixes around the code rather than in it |
| A few endpoints missing authorization checks, and a clear owner column on records | Harden, then add automated access tests so the fixes stay fixed |
| Records with no clear owner, permissions checked differently on every route, or security rules that are hard to write down | Rebuild the data and permission layer, and keep the interface |
| Failures in both access control and the data model, plus payments or health data | Rebuild with a security review before launch |
The table is a judgment, not a measurement. It is the same question you would ask of any inherited codebase: can a person who did not write it prove who may read what?
What to do this week
- Freeze new features until the checks pass.
- Run checks 1 to 3 first. They are the cheapest to run and they catch the failures that expose customer data.
- Write the access tests as code (two users, one table, one assertion per endpoint) so they run on every change. Supabase's docs suggest the same for policies: until the tests pass, you do not know whether they do what you intended.
- Fix, then run each failed check again. A fix is proven by the test that failed.
- Put the remaining checks in a launch gate, and keep the results with the date.
If you want a second pair of eyes on a prototype, our MVP codebase audit reviews auth, sessions and role-based access, secrets management, dependency hygiene and the OWASP Top 10. Our AI MVP checklist covers the rest of the launch gate.
Limits of this page
We read the sources on 22 October 2026: the Veracode blog (not the full report), the National Vulnerability Database record, Supabase's row-level security documentation, the arXiv abstract and the OWASP Top 10:2025 page. We did not test any AI builder, run any scanner or audit any app, so nothing here says that a particular tool produces unsafe apps. The percentages come from different sources with different test designs, so they are not comparable with each other. The checks, the table for harden or rebuild and the order are our own and are not security or legal advice.
Sources
- 2025 GenAI Code Security Report, Veracode, 30 July 2025
- CVE-2025-48757, National Vulnerability Database, published 30 May 2025
- Row Level Security, Supabase documentation
- We Have a Package for You!, a study of package hallucinations by code-generating LLMs, Spracklen and others, arXiv, June 2024
- OWASP Top 10:2025, OWASP