Vibe-Coded App Security Checklist: 15 Checks Before You Launch

In short: Apps built quickly with AI coding tools and app builders tend to fail security in predictable places: anyone can read data they should not, secret keys sit in the browser, and nobody checks inputs, dependencies or backups. None of this means you should stop building that way. It means you need a short, boring checklist before real users and real data arrive. Here are 15 checks, in the order we would run them.

Key takeaways

• Broken access control is the number one risk in the OWASP Top 10, and it is the most common gap in fast-built apps.
• If you use Supabase or a similar backend, row level security policies are your real permission system. Test them as an anonymous user and as a second user.
• Secret keys never belong in frontend code, environment files committed to git, or the AI tool's chat history.
• Research shows people using AI code assistants can write less secure code while feeling more confident about it. Plan for review.

Why vibe-coded apps need their own checklist

"Vibe coding" usually means describing what you want to an AI tool and accepting most of what it writes. It is a fast way to get a working product. The risk is that "working" and "safe" are different tests, and the AI optimizes for the first one unless you ask for the second.

The research is consistent on this. A 2021 study of GitHub Copilot found that roughly 40% of the programs it generated in security-relevant scenarios were vulnerable (Pearce et al., Asleep at the Keyboard). A Stanford user study found that participants with an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure (Perry et al., 2022). Models have improved since, but the second finding, overconfidence, is the one to design around.

A real example: in 2025 a CVE was published describing insufficient row level security policies in apps generated with Lovable that could let unauthenticated users read or write database tables. The vendor disputed it, stating that each customer is responsible for protecting their own app's data (NVD, CVE-2025-48757). Whoever is right about responsibility, the practical lesson is the same: you own your app's access rules.

The checklist

Access control (the big one)

1. List every table and who should read and write it. Make a simple table: data, owner, who can read, who can write. If you cannot fill it in, the AI could not either.

2. Turn on row level security for every table exposed to the client. In Supabase, RLS policies decide which rows each user can access, and tables without RLS in an exposed schema can be reachable with the public key (Supabase, Row Level Security). Check that every table has RLS enabled and a policy that matches your list from check 1.

3. Test as a stranger and as another user. Log out and try to load data. Then log in as user B and try to read or change user A's records by changing IDs in requests. This catches the most common failure in the OWASP Top 10, broken access control (OWASP Top 10:2025, A01).

4. Enforce permissions on the server, not by hiding buttons. If the admin page is hidden in the UI but the API allows the action, it is not protected. OWASP's guidance is to deny by default and check authorization on every request (OWASP Authorization Cheat Sheet).

Secrets and keys

5. Search the frontend bundle for secrets. Open your deployed site, view the loaded JavaScript, and search for "sk_", "secret", "service_role", and your provider names. Supabase's documentation is direct about this: the secret key bypasses row level security and must never leave your control, while the publishable key is designed to be public (Supabase, API keys). The same logic applies to AI provider keys. We wrote a dedicated playbook on containing client-side AI provider keys.

6. Check git history, not just current files. A key deleted from code is still in history. Turn on secret scanning in your repository host (GitHub, About secret scanning) and rotate any key that was ever committed.

7. Store secrets in your hosting platform's secret manager and give each key the least access it needs (OWASP Secrets Management Cheat Sheet). Avoid pasting production keys into AI chat sessions.

Authentication

8. Use your platform's built-in auth, not a custom one the AI wrote. Check that email verification, password reset, and session expiry work as you expect. Make sure sign-up cannot be used to create admin accounts.

9. Protect admin and internal tools separately. Require a role check on the server and, where possible, multi-factor authentication for admin users.

Inputs and outputs

10. Validate every input on the server. Types, lengths, allowed values, file types and sizes for uploads. Client-side validation is for user experience only.

11. Check for injection and unsafe rendering. Use parameterized queries or your ORM, and avoid rendering user content as raw HTML. If your app passes user text to an AI model that can take actions, read our AI security playbook on prompt injection.

12. Do not leak details in errors. Stack traces, SQL errors and internal IDs in error messages help attackers. Log them on the server, show a plain message to users.

Dependencies, operations and recovery

13. Turn on dependency alerts and review what the AI installed. AI tools sometimes add packages you do not need. Remove unused ones and enable alerts for known vulnerabilities (GitHub, About Dependabot alerts). Supply chain failures are now their own category in the OWASP Top 10:2025.

14. Log security-relevant events and set one alert. Sign-ins, failed sign-ins, permission errors, admin actions. At minimum, get alerted on spikes in errors or permission denials.

15. Back up the database and test a restore. Confirm backups are on, know how far back they go, and restore once into a test project. A backup you have never restored is a guess.

How to run the checklist without a security team

• Ask the AI to review its own work, but specifically. "Review this app for security" gets vague answers. "List every table, its RLS policy, and show me a request that would let user B read user A's data" gets useful ones.
• Use a review gate for every change. Fast builders ship many small changes, and each one can reopen a hole. Our pre-merge review gate for vibe-coded changes shows a lightweight way to do this.
• Get a second pair of eyes before launch if you store personal, payment or health data. An outside review of access control and secrets takes days, not months.

FAQ

Is vibe-coded software insecure by default?

Not by definition, but it is unreviewed by default. Studies have found AI-generated code often contains vulnerabilities and that users tend to overtrust it. A checklist and review close most of the gap.

What is the most common security problem in apps built with AI tools?

Access control: missing or overly broad database policies and APIs that do not check who is asking. That matches the OWASP Top 10, where broken access control is first.

Is the Supabase anon or publishable key a secret?

No. It is designed to be public and relies on row level security to protect data. The secret or service role key is the one that must never reach the browser.

Do I need a penetration test before launch?

For a simple app with no sensitive data, this checklist plus a peer review is a reasonable start. If you handle payments, health data or other people's personal data at scale, get a professional review.

Can I ask the AI tool to fix security issues for me?

Yes, and it often can, but verify each fix with the tests in checks 3 and 5. Treat the AI's "this is secure" as a claim to test, not a result.

How Octacer can help

We take apps built with AI tools and make them production-ready: access control reviews, secrets cleanup, auth hardening, monitoring and backups, without rewriting what already works. See our prototype to production and system rescue services, or book a call.

Sources

• Pearce, H. et al. (2021). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions: https://arxiv.org/abs/2108.09293
• Perry, N. et al. (2022). Do Users Write More Insecure Code with AI Assistants?: https://arxiv.org/abs/2211.03622
• NVD, CVE-2025-48757: https://nvd.nist.gov/vuln/detail/CVE-2025-48757
• OWASP Top 10:2025: https://owasp.org/Top10/2025/
• OWASP Top 10:2025, A01 Broken Access Control: https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
• OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
• OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
• Supabase, Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
• Supabase, Understanding API keys: https://supabase.com/docs/guides/api/api-keys
• GitHub Docs, About secret scanning: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
• GitHub Docs, About Dependabot alerts: https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts