Free checklist · no sign-up
The vibe-coder’s security checklist.
AI builders produce apps that look finished, and the security gaps are rarely visible from the screen. These are 15 checks for the issues that come up most often in AI-generated apps, each with a test you can run yourself. Many relate to risks in the OWASP Top 10. Start with the High severity items.
- 01High
Secret API keys in front-end code
Check: Open your browser’s developer tools (Sources and Network tabs) and search for “key”, “token” and “secret”. Publishable keys, such as a Supabase publishable (anon) key or a Stripe publishable key, are designed to be public. Secret keys, service-role keys and third-party API keys (an OpenAI key, for example) are not. If you find one, move that call to the server and rotate the key.
- 02High
Login that is only enforced in the browser
Check: Copy the URL of a logged-in page and open it in a private window, or call the API it uses without a session. If the data still comes back, the login check lives in the interface and the server is not enforcing it.
- 03High
No row-level security or per-user access rules
Check: Signed in as user A, change an ID in a request (or the URL) to one belonging to user B. If B’s data comes back, access is not being enforced where the data lives.
- 04High
Database tables reachable from the browser without access rules
Check: If the browser queries your database directly (common with Supabase), that is only safe when row-level security is enabled on every exposed table, with policies that match your rules. Check each table in your database dashboard. A table without row-level security can be read or changed by anyone holding the public key.
- 05High
No server-side input validation
Check: Send unexpected input straight to the API rather than through the form: very long text, script tags, wrong data types, negative quantities. If the server accepts it, add validation on the server; checks in the form alone can be bypassed.
- 06High
Secrets committed to the code repository
Check: Search the repository and its history for keys, passwords and .env values. Anything found should be rotated (deleting it from the latest version is not enough) and moved into environment variables or your host’s secrets store.
- 07Medium
No rate limiting
Check: On your own app, call a login, sign-up or AI-powered endpoint many times in quick succession. If nothing slows you down, you are open to password guessing, spam sign-ups and unexpected usage bills.
- 08Medium
Overly permissive CORS
Check: Check which websites your API accepts browser requests from. A wildcard (*) is acceptable for genuinely public data; for anything behind a login, allow only your own domains.
- 09Medium
Pages or requests not on HTTPS
Check: Confirm every page loads over HTTPS and the browser console shows no “mixed content” warnings for scripts, images or API calls.
- 10Medium
Error messages that expose internals
Check: Trigger an error, for example by submitting a broken form or visiting a missing record. If users see stack traces, database queries or file paths, log the detail privately and show a plain message instead.
- 11High
Unprotected admin or internal endpoints
Check: List every admin page, internal API route and scheduled job. Each should require a signed-in user with the right role. A hard-to-guess URL is not protection.
- 12High
Passwords handled insecurely
Check: Passwords should be hashed by a proven auth service or library, never stored in plain text and never written to logs. If the AI tool wrote its own login system, replace it with a managed auth provider.
- 13Medium
Unreviewed dependencies
Check: Run your package manager’s audit (npm audit, for example) for known vulnerabilities, update what it flags and remove packages the app no longer uses.
- 14Medium
Unrestricted file uploads
Check: If users can upload files, check that type and size are limited on the server, uploaded files cannot run as code, and private files are not reachable at a public or guessable URL.
- 15High
No backups or recovery plan
Check: Confirm the database is backed up automatically, check how far back you can restore, and do a test restore. A backup nobody has restored is an assumption, not a plan.
FAQ
Frequently asked questions
Is vibe coding safe?
For prototypes, yes. Once an app holds real customer data or takes payments, it needs the same security checks as any other software, and AI-built apps often skip some of them: secret keys left in browser code, login checks that only exist in the interface, database tables without access rules, and input the server never validates. The app can look finished while these gaps are there. This checklist helps you find them before customers rely on the app.
What are the most common security issues in AI-generated apps?
The ones we see most are secret keys exposed in front-end code, login enforced only in the browser, missing row-level security (so one user can read another’s data), and no validation on the server. Several fall under categories in the OWASP Top 10 (2025 edition), the widely used list of web application security risks, such as Broken Access Control and Authentication Failures. All of them are fixable.
How do I secure an app I built with Lovable, Bolt or Replit?
Work through the High severity items first: move secret keys to the server, enforce login and access rules on the server or database, turn on row-level security for every exposed table, and validate input on the server. Then work down the Medium items. If you would rather have engineers do it, we can review the app and tell you what needs fixing.
Found items you are not sure how to fix?
Send us the app or repo. We will review it, tell you which issues are real and which are fine as they are, and how much work the fixes involve.