Buyer Guides · 6 MIN
Vibe-coded app security checklist: 12 checks before you launch
A 12-point security checklist for apps built with AI tools like Lovable, Bolt, Cursor or Claude Code, mapped to the OWASP Top 10:2025, with how to test each check yourself.
Before launching an app built with AI tools, check twelve things: access rules on every table and endpoint, sign-in and session handling, secrets kept out of the browser, input validation, dependency health, security settings, payment verification, file upload limits, rate limits, error handling, logging, and prompt injection if the app uses an AI model. The checklist below maps each one to the OWASP Top 10:2025, a widely used list of web application security risks, and says how to test it without being a security specialist.
- "Vibe coding" means building software mostly by describing it to an AI tool and accepting what it writes. It is fast, and it skips the questions a security review would ask.
- Broken access control is number one in the OWASP Top 10:2025, and OWASP reports that 100% of the applications it tested had some form of it.
- Most launch-blocking problems in AI-built apps are about who can read or change what, not exotic attacks.
- Test with two real accounts: sign in as one user and try to reach the other user's data.
- If the app calls an AI model, treat every piece of text it reads as untrusted, because of prompt injection.
- Nactore is a technology and growth company that reviews and hardens AI-built apps before they meet real users.
Why are AI-built apps a special case?
AI coding tools are very good at producing code that runs. They are less reliable at the parts nobody asked for: who is allowed to do what, what happens when input is hostile, and which keys must never leave the server. A human engineer adds those by habit. An AI tool adds them when the prompt or the platform demands it.
That is not a reason to avoid these tools. It is a reason to run a checklist before launch, the same way a pilot does before take-off, however experienced.
The 12 checks
| # | Check | OWASP 2025 category | How to test it |
|---|---|---|---|
| 1 | Every table and API endpoint checks who is asking | A01 Broken Access Control | Two accounts: can user A read or edit user B's data? |
| 2 | Users cannot change their own role, plan or price | A01 Broken Access Control | Edit the request in browser dev tools and resend it |
| 3 | Sign-in, reset and session expiry work properly | A07 Authentication Failures | Reset a password, then check old sessions are logged out |
| 4 | No secret keys in frontend code or the repo history | A04 Cryptographic Failures, A02 Security Misconfiguration | Search the built JavaScript and git history for key patterns |
| 5 | Inputs are validated on the server | A05 Injection | Submit oversized, empty and special-character input to each form |
| 6 | Dependencies are current and known-safe | A03 Software Supply Chain Failures | Run your package manager's audit command |
| 7 | Production settings are locked down | A02 Security Misconfiguration | Debug off, default accounts removed, admin pages not public |
| 8 | Payments are confirmed by verified webhooks | A08 Software or Data Integrity Failures | Fake a success redirect without paying: is anything unlocked? |
| 9 | Uploads have size, type and privacy limits | A06 Insecure Design | Upload a huge file and an unexpected file type |
| 10 | Sensitive endpoints are rate limited | A06 Insecure Design | Send many sign-in attempts quickly |
| 11 | Errors fail safely and do not leak details | A10 Mishandling of Exceptional Conditions | Trigger an error and read what the user sees |
| 12 | Security events are logged and alert someone | A09 Security Logging and Alerting Failures | Fail sign-in several times: does anyone find out? |
The three that matter most
Access control on the database
Many AI-built apps use Supabase, where the browser talks to the database through an API. Supabase's Row Level Security guide says a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and tells you to enable RLS on every table in an exposed schema. Row Level Security is a set of database rules that decide, row by row, who may read or change data.
If you check only one thing before launch, check this one.
Secrets in the browser
Anything sent to the browser is public. Supabase's API key guide explains that the publishable key can be shipped because Row Level Security limits it, while the secret key bypasses Row Level Security and must never leave your control. Apply the same rule to payment, email and AI provider keys: they belong in server-side code only. OWASP's secrets management cheat sheet notes how often secrets end up hardcoded in source code in plain text. If a key was ever committed, rotate it.
Trusting the browser about money
A common AI-generated pattern unlocks a paid feature when the user lands on a "payment successful" page. Anyone can visit that page. The only proof of payment is a webhook from the payment provider, verified with its signature, processed on your server, and processed once even if it arrives twice.
If your app uses an AI model
Apps that call a language model have an extra risk. OWASP's LLM01:2025 Prompt Injection describes how input can push a model to violate its guidelines, enable unauthorized access or influence critical decisions, and notes that the input does not even need to be visible to a human.
Practical limits:
- Give the model the least access it needs. A support bot does not need write access to orders.
- Treat model output as untrusted input. Validate it before it reaches a database query, an email or a payment.
- Keep a human approval step for actions that move money or change accounts. See human-in-the-loop automation.
What a checklist does not cover
A checklist catches common problems. It does not replace a review by someone who reads your specific business logic, and it is not a penetration test. For apps holding health, financial or large volumes of personal data, budget for a professional security assessment and check your legal obligations.
Frequently asked questions
Is AI-generated code less secure than human code?
It depends on who reviews it. AI tools write code quickly and can miss security rules nobody asked for. The fix is the same as for human code: review, tests and a checklist.
Can I run these checks without an engineer?
Several, yes: the two-account test, the payment redirect test and the upload test need only a browser. Checks on secrets, dependencies and server settings are easier with an engineer.
What is the OWASP Top 10?
A list of the most important web application security risks, maintained by the OWASP Foundation and updated every few years. The current edition is the Top 10:2025.
Do Lovable's built-in scans cover this?
Lovable offers Quick and Deep security scans. Use them, then review the business logic and access rules they cannot judge. Our Lovable to production guide covers the full path.
Launch fast, launch safe
The speed of AI tools is real. So is the cost of a data leak in week one. Nactore takes AI-built apps from prototype to production: security review, database rules, payments, tests and monitoring, so you keep the speed without the risk.
Want a pre-launch review of your app? Book a free 30-minute call.
Want to apply this to your business?
Book a free 30-minute call. We will tell you what we would do first.