Is your AI-built app leaking data? A 10-point security checklist for non-developers

Your AI-built app might be leaking data, and you can check it yourself in under an hour. Two studies in 2026 found thousands of apps made with AI tools that exposed personal data, mostly because of a few simple settings: database tables anyone could read, secret keys shipped inside the app, and pages with no sign-in. This security checklist covers the ten things to check, in plain words.

In short

• On May 7, 2026, Axios reported that security firm RedAccess found 380,000 publicly accessible apps and sites built with AI app-building tools, and about 5,000 of them exposed sensitive corporate or personal data (Axios, Security Boulevard).
• In September 2026, UpGuard reported 16,326 Supabase databases with tables anyone could read, out of about 300,000 sites it checked. More than half showed signs of personal data, and some held passwords or login tokens (UpGuard, BleepingComputer).
• The main causes named in these reports: row level security not turned on, public keys treated as if they were secret, and apps left public and indexed by search engines.
• Most of these are settings, not hard engineering. You can check every one of them without writing code.

Is vibe coding safe?

It can be. Building with AI (often called vibe coding) is not unsafe by itself. The problem in the reports above is that an app can work perfectly on screen while its data is open underneath. Nothing looks wrong to you, so nothing gets fixed.

One example from Supabase's own docs: tables created in the Supabase dashboard's Table Editor have Row Level Security on by default, but tables created with SQL do not (Supabase docs). If a tool creates your tables with SQL, it is worth checking.

Row level security, explained in one minute

Many AI-built apps store data in a hosted database such as Supabase. The app talks to it with a public key that is inside the app, so anyone who downloads the app can find that key. Supabase says this is fine, but only when Row Level Security (RLS) is on: rules inside the database that decide which rows each user may see or change (Supabase API keys docs).

Without RLS, the public key opens the table. Supabase's checker puts it plainly: anyone with your project URL can read, edit and delete all data in that table (Supabase linter).

The 10-point security checklist

1. Row level security is on for every table. In Supabase, open Advisors and look at the Security Advisor. It flags tables without RLS (Supabase Advisors). Every table in the public schema should have it on.

2. Each private table has rules tied to the signed-in user. A notes or orders table should let a user see only rows where the owner is that user. Watch for a rule that says using (true) on private data: it means "every row".

3. Secret keys are not inside the app. A Supabase service_role or secret key, an AI provider key, a payment secret key: none of these may be in the app or website. Anything inside an app can be dug out. Supabase says its secret keys must never go in "a shipped application" (Supabase API keys docs).

4. You tested it signed out. Open your app without signing in, or in a private browser window. Can you see anyone's data? Can you add or change something? If yes, something is open that should not be.

5. You tested it as a second user. Make two accounts. Add something private with the first, then sign in with the second. You should not see it.

6. Anything personal needs a sign-in. Messages, orders, bookings, health notes, photos of people: these should only be reachable by signed-in users, and only their own. Only truly public data (a menu, a price list) should be readable without signing in.

7. You know who can open your app. The RedAccess research found apps that were public unless someone changed a setting, and many were indexed by search engines. Check whether your app's link and any test pages are private or public, and who has the link.

8. You do not store passwords yourself. UpGuard's examples included plain text passwords in open tables. Use a real sign-in system (such as Supabase Auth) instead of a "passwords" column in your own table.

9. You collect only what you need. Data you never store cannot leak. Skip ID scans, full birth dates and similar fields unless the app really needs them. For payments, use a hosted checkout page so card numbers never touch your app.

10. You have a plan if a key leaks. Set a spending limit at your AI provider. If a secret key ends up somewhere public, revoke it in the provider's dashboard, create a new one and replace it. Re-run this checklist after every big change to your app.

A related change: from October 30, 2026, Supabase no longer opens new tables to its API automatically. If you see "permission denied for table", read how to fix Supabase error 42501 safely before you change any settings.

How Snapp handles your keys

Snapp is an AI app builder for iPhone and Android apps. Snapp Vault keeps your app's secret keys out of your app:

• Secret keys you add (for an AI provider, your database or payments) are stored encrypted with Snapp and do not go inside your app, so they do not appear in your mobile app or on your website.
• Snapp works out which keys are secret. Keys designed to be public, like a Supabase project URL or a Stripe Payment Link, stay in the app as intended.
• Your app's preview files can only be opened by you and the people you share your app with.
• There is nothing to set up: you add keys on your app's keys screen as usual.

When you connect Supabase, only the project URL and the public anon key go inside your app. The service role key and the database password stay in Snapp Vault. The database is your own Supabase project, so points 1, 2, 4 and 5 above are still worth checking on it, especially for anything you change by hand.

Read more: Introducing Snapp Vault, connect Supabase to your app and add login and authentication. You can try Snapp at snappai.co.

Frequently asked questions

Is the Supabase anon key a secret?

No. Supabase designs the anon (or publishable) key to be inside apps and websites. It is only safe when Row Level Security is on and your rules limit what it can reach. The service_role and secret keys are the ones that must stay out of your app.

What is row level security in simple words?

It is a set of rules inside the database that decides, row by row, who can see or change data. For example: "a user can only read notes where they are the owner". Without it, anyone holding your app's public key can reach the whole table.

How do I know if my app's data is already exposed?

Open the app signed out and try to see or change data, then run the Security Advisor in your Supabase dashboard. If you find an open table, turn on RLS, add rules, and change any secret key that was inside the app.

Do I need to be a developer to secure my app?

No. The ten checks above are about settings and testing, not writing code. If your builder or database shows a security warning, read it and fix it before you share the app.

Sources

• Axios: Thousands of AI-built apps exposed sensitive corporate and personal data, researchers found (May 7, 2026)
• Security Boulevard: RedAccess research on exposed apps (May 2026)
• UpGuard: Systemic data exposure in Supabase apps
• BleepingComputer: Over 16,000 Supabase databases expose data (September 28, 2026)
• Supabase docs: Row Level Security
• Supabase docs: API keys
• Supabase docs: Advisors
• Supabase linter: RLS disabled in public

Last updated: October 2026.