Vibe-Coded App Security Checklist (2026)
After 16,000 exposed Supabase databases, a 10-point security checklist for AI-built apps: access rules, keys, roles, and when a human must review.
As of October 2026, the biggest security risk in a vibe-coded app is rarely the AI model itself. It is configuration nobody checked: database tables open to the public, secret keys shipped to the browser, and pages that show one user's records to another. On September 25, 2026, TechCrunch reported that security firm UpGuard had found around 16,000 Supabase databases exposing personal data such as names, addresses, phone numbers and passwords through basic misconfigurations. Below is a ten-point checklist to run before you launch an app built with an AI builder, and a guide to which findings you can fix yourself and which need a developer.
What happened with the 16,000 exposed Supabase databases?
UpGuard found around 16,000 databases on Supabase, a popular backend for apps built with AI tools, that were exposing people's data to the web. The data included names, addresses, phone numbers, passwords, authentication tokens, licence plates and private conversations.
TechCrunch's report put the cause down to basic misconfiguration and weak security set-up, not a flaw in Supabase itself. It also noted the wider pattern: AI tools make it easy to build websites and apps, but the generated code can contain security flaws, or the app may need configuration the person building it doesn't know about. Supabase's chief information security officer, Bil Harmer, described security as a shared responsibility: the company provides secure defaults and tooling, and customers control how their projects are configured.
That is a fair summary of every hosted platform. The tools give you safe options. Someone still has to switch them on and check them.
Why do vibe-coded apps leak data so often?
Vibe coding means building software mainly by describing what you want to an AI tool and accepting the code it writes, often without reading that code line by line. The app can look finished long before anyone has checked who is allowed to see what.
Three things make leaks more likely:
- The demo works either way. An app with no access rules behaves exactly like an app with correct ones when you are the only user. Problems appear only when a second user, or a stranger, sends a different request.
- The prompts are about features. "Add a dashboard showing my orders" gets you a dashboard. It doesn't automatically get you a rule saying a user may see only their own orders.
- AI-written code still contains the usual flaws. In August 2025, Veracode reported that 45% of AI-generated code samples it tested introduced vulnerabilities from the OWASP Top 10, and its March 2026 follow-up found no improvement, according to a Cloud Security Alliance research note. Georgia Tech's Vibe Security Radar project had confirmed 74 CVEs linked to AI coding tools by March 2026, rising from six in January to 35 in March.
None of this means AI-built apps are unusable. It means they need the same review any other app needs before real users' data goes in.
What should you check before launching an AI-built app?
Run this list against the live app, not the preview. Most items take a few minutes each. Use a second test account, and a browser window where you are not logged in at all.
- Database access rules are on for every table. If you use Supabase, Row Level Security must be enabled on every table in an exposed schema such as public, with policies that say who can read and write each row.
- No secret keys in the browser. Open your site, view the page source and the JavaScript files, and search for "secret", "service_role", "sk_" and your payment or email provider's key names. Public "anon" or "publishable" keys are meant to be visible; secret keys are not.
- One user can't see another user's records. Log in as user A, open a record, and change the ID in the address bar or the API request to one that belongs to user B. You should get an error, not B's data.
- Admin pages need an admin. Try /admin, /dashboard and similar paths while logged out and while logged in as an ordinary user.
- Sign-up can't grant itself a role. Check that a new user can't set "role": "admin" or a similar field in the sign-up request.
- File uploads are limited. Restrict file types and sizes, and make sure uploaded files aren't publicly listable unless they are meant to be.
- Every form is validated on the server. Checks only in the browser can be skipped by sending the request directly.
- Dependencies are current. Update the framework and libraries, and fix anything your package manager's audit command flags as critical or high.
- Errors don't reveal internals. Error pages and API responses shouldn't show stack traces, database queries or keys.
- You can see who did what. Keep logs of sign-ins, admin actions and data exports, so you can answer questions if something goes wrong.
Items 1 to 4 cover the categories at the top of the OWASP Top 10:2025, where Broken Access Control is first and Security Misconfiguration second.
How do you check Row Level Security in Supabase?
Supabase's documentation is direct: enable RLS on every table in an exposed schema. Once RLS is enabled, no data is accessible through the API with a publishable key until you create policies that allow it. That gives you a simple test.
| What you see | What it usually means | What to do |
|---|---|---|
| RLS disabled on a table in the public schema | Anyone with your public key can read or change that table through the API | Enable RLS, then write policies |
| RLS enabled, no policies | Nothing is readable through the API; the app may break | Add policies for the access the app needs |
| A policy like "true" for select | Every row is readable by everyone | Narrow it, for example to rows where the user ID matches the signed-in user |
| The service_role key in front-end code | The key bypasses RLS entirely | Remove it, rotate it, and move that logic to the server |
| Policies on select only | Reads are protected, writes may not be | Add insert, update and delete policies too |
Whatever tool reports on your tables, treat its findings as a starting list, then do test 3 above by hand.
Which problems can a scanner catch, and which need a human?
Automated tools are good at finding known patterns. They are weak at judging whether your app's rules match your business.
| Problem | Scanner or advisor | Needs a person |
|---|---|---|
| Table with RLS disabled | Usually catches it | — |
| Secret key in front-end code | Often catches it | Confirming what the key can do |
| Outdated library with a known flaw | Catches it | Deciding how to upgrade safely |
| User A can read user B's records | Rarely | Yes: needs two accounts and knowledge of who should see what |
| A partner role that can export everything | No | Yes: only the business knows the intended limits |
| A payment flow that trusts the price sent by the browser | Rarely | Yes |
| An old test page still online | Sometimes | Yes: someone has to decide it should go |
You can also ask the AI tool that built the app to review its own code. That can find real issues, and it's worth doing. But it reviews against the code it can see, not against what your business intended, so the access questions in the right-hand column still need a person.
When should you rebuild instead of patching?
Patching makes sense when the problems are configuration: switching on RLS, moving a key to the server, adding validation. A rebuild is worth considering when:
- access rules would have to be added to almost every screen and query, because the app was never designed around roles;
- nobody can say which code is in use, and changes in one place keep breaking another;
- the app is about to handle payments, health information or other sensitive data it wasn't designed for;
- you need features the builder's platform can't support, such as a specific payment gateway or an on-premises integration.
A common path is to keep the AI-built version as a validated prototype, then build the production system with roles, data rules and tests designed in from the start. Our article on AI automation with human review covers where people should stay in the loop once an AI system is live.
What we do on client projects
We build with AI ourselves, so this isn't a warning against it. We develop and review code every day with Claude Code, an AI coding agent, and a person reviews each change before it ships. On our projects that review covers the same ground as the checklist above:
- Permissions designed per role, with every data request checked on the server.
- Input validation on forms and APIs.
- Dependency patching for the framework and libraries.
- Exposure checks before launch: which pages, admin paths and files are reachable from outside.
We are a two-person studio, the CEO and a director, and we build each project ourselves, mostly in Next.js, often with a PostgreSQL database. We don't offer standalone security audits or penetration testing, and no one can guarantee an app will never be attacked. What we offer is development: fixing and finishing an AI-built app you already have, or rebuilding it for production. Hosting and maintenance are agreed in a separate contract. For how we work with clients abroad, see outsourcing software development in South Korea.
Frequently asked questions
Is vibe coding safe for a production app?
It can be, if the result gets the same review as any other app before real data goes in. The risk is in skipping that step: access rules, secret keys and server-side checks are where AI-built apps most often go wrong.
What does "RLS disabled in public" mean in Supabase?
It means a table in the public schema has Row Level Security turned off, so anyone with your project's public key can read or change it through the API. Enable RLS on every exposed table and add policies for the access the app needs.
Can I just ask the AI to fix the security issues?
Partly. An AI tool can find and fix many configuration and code problems, and it's worth asking. It can't know your intended rules, such as which staff role may export customer data, so test access with real accounts and have a person review the result.
Are apps built with Lovable or Bolt secure?
The builder doesn't decide that on its own. Apps made with any AI builder can be secure or insecure depending on how the database, keys and access rules are set up. Run the checklist above against the live app, whichever tool made it.
How much does it cost to fix or rebuild an AI-built app?
It depends on the app's size, how many roles and integrations it has, and how much needs fixing or rebuilding. We quote after looking at the code and what the app must do; we don't publish a fixed price.
Sources
All checked October 2026.
- TechCrunch, Some Supabase customers are publicly exposing reams of people's data to the web, September 25, 2026
- Supabase, Row Level Security documentation
- OWASP, OWASP Top 10:2025
- Cloud Security Alliance, Research note on AI-generated code vulnerabilities, April 4, 2026, citing Veracode (August 2025 and March 2026) and Georgia Tech's Vibe Security Radar
Built your MVP with an AI builder and want it ready for real users? See how we build web apps on our web services page, then send us your project details, with the repository link or up to three files, or email dwkim@nqsolution.kr.