Skip to content

Stop vibe-coded apps exposing data

Most data exposures in vibe-coded and other AI-built apps come from configuration, not hacking. The usual causes are tables and storage that are public by default, API keys exposed in front-end code, and missing row-level security. Fix them with five controls: deny-by-default data rules, secrets kept on the server, negative access tests, an external exposure scan before launch and on a schedule, and a named owner who answers for fixes and stays reachable. This page covers the documented cases as of October 2026, how to test your own app without being a developer, and where secrets leak.

Who this is for

Security leads, platform teams and builders on AI app builders, low-code tools and hosted databases. You get the causes, a test you can run yourself, the site's canonical guidance on secrets, and what to do if data got out.

Why do AI-built apps expose data?

Most apps have three parts: the screens you see (the front end, which runs in each visitor's browser), a database, and the rules that decide who may read or change each row. An AI app builder generates all three from a prompt. It's good at the screens and much less reliable at the rules, because a missing rule doesn't show up as a broken screen. The app works for you, but anyone who knows the address can read the data.

Anything sent to the browser can be read by anyone who opens the app, including keys. Some keys are designed to be public: a hosted database's "anonymous", "public" or "publishable" key is safe only if the data rules are on. Others, such as a database's service-role or admin key, or an AI service's secret key, must never reach a browser.

One security vendor reports scanning about 1,400 vibe-coded apps and finding more than 2,000 highly critical vulnerabilities, more than 400 exposed secrets and 175 exposures of personal data; the page gives no date and only partly describes its method, so treat it as vendor research1.

Which vibe-coded app data exposures are documented?

Fast-moving

As of October 2026. Check the review date.

When What happened Root cause The vendor's response
Aug 2021 Power Apps portals with table permissions off let anonymous visitors read lists: 47 organizations, about 38 million records, including Social Security numbers2 Public-by-default setting "By design" at first, then table permissions on by default2
Mar 2024 At least 900 sites on a hosted database had open rules: about 125 million records, including plaintext passwords. About a quarter of contacted owners fixed it3 Open data rules; unresponsive owners Customer configuration
2023–26 CRM customer-portal guest profiles let unauthenticated visitors query records; attackers mass-scanned for them (reported Mar 2026)4 5 Guest access too broad Customer configuration4
Jan 2025 An AI company's analytics database had no authentication: over a million log lines, including chat history and API secrets6 No authentication on a production datastore Secured promptly6
May 2025 CVE-2025-48757: an AI app builder's generated projects lacked row-level security, so unauthenticated users could read or write tables (severity 9.3)7 No row-level security; database key in the client Vendor disputes the CVE7
Jul 2025 An AI app builder's sign-up flow let anyone with a public app ID join private, single-sign-on apps, including ones holding HR data8 A platform flaw that reached every app on it Fixed in under 24 hours
Jul 2025 A legacy storage bucket left publicly readable exposed about 72,000 user images (not shown to be AI-built)9 A legacy resource left public —
Jan 2026 An AI chat app's open hosted database exposed about 300 million messages from more than 25 million users10 Open data rules Fixed within hours
Feb 2026 A vibe-coded social network had its database key in front-end JavaScript and no row-level security: 1.5 million API tokens and 35,000 emails exposed11 Missing row-level security; secrets in the client Patched within about 3 hours
Feb–Apr 2026 An AI app builder's own regression exposed public projects' code and chat history12 A platform regression Published a post-mortem12

This table covers exposures only. The full dated log of incidents, with root causes, is in security incidents. There's no public, named case of a worker-built low-code app causing a financial loss; the public record is exposures.

Don't: assume a new app is private (AP1: public-by-default data)

In the Power Apps, hosted-database and storage-bucket cases, nobody chose to publish the data; a default did. Assume every new table, bucket, form and share link is public until you've checked it2 3. A builder tool that can't keep a Sandbox app private isn't approved for Sandbox use (Floor 2).

Don't: rely on \"the vendor secured it\" (AP3)

Vendors answered several of these cases with "by design" or "customer configuration", and one disputes the CVE filed against it2 4 7. On every platform, the vendor secures hosting, patching and its own sign-in; you secure the data rules on every table and bucket, which key goes where, guest and sharing settings, and what data goes in. Platforms also fail on their own (the July 2025 and April 2026 rows), so approve them as suppliers.

What are the five controls that stop exposures?

These controls would have caught every configuration case in the table. The risk tier decides when each is required, not this page.

  1. Deny-by-default data rules. Nobody can read or change a row in any table or bucket until a rule allows it. Turn on row-level security (or the platform's equivalent) before you add any data. On PostgreSQL-based backends such as Supabase the setting is called row-level security (RLS); Firebase calls its version security rules. (Deploy gate.)
  2. Secrets stay on the server. No secret key in the front end, the code or the prompts. Calls that need a secret go through a server-side function that holds it. See secrets below.
  3. Negative access tests. Prove that someone without access sees nothing: a signed-out visitor, a second test account, a user from another team. Seeing your own data proves nothing about exposure. (Verify gate.)
  4. An external exposure scan, before launch and on a schedule. An exposure scan checks from outside that the app's data, storage and URLs can't be reached without sign-in. Settings drift, so repeat it. It confirms a Floor 2 fix under the floor-breach rule.
  5. A named, reachable owner answers for fixes. The technical reviewer records the scan; the app owner is named in the app registry, so everyone knows who to call, and answers for fixes. In the March 2024 case, about three in four contacted owners never fixed their exposure3.

Don't: put the database key in the browser without row-level security (AP2)

The May 2025 CVE and the February 2026 exposure both combined a database key in front-end code with missing row-level security7 11. If your app talks to its database straight from the browser, we recommend row-level security with a negative test at every tier; the gate matrix requires negative access tests from Important up.

How do you test your app without a developer?

Do these before you share the app, and after every change to sharing, data or sign-in (about 30 minutes). Record the results in the app record.

Don't: test someone else's app, or production with real data

Test only an app you own or have written permission to test, with test accounts and test rows, never real customer or staff records. An active scanner is an attack: OWASP ZAP's documentation says not to use it on apps you don't own13. It submits forms, can change or delete data, and may break a hosting platform's terms.

  1. Signed-out test. Open the app's address, and the addresses of inner pages, in a private browser window, signed out of everything. You should see a sign-in page and nothing else.
  2. Second-account test. Sign in as a test account with the lowest role, or ask a colleague outside the team. They should see only what that role allows: no other users' records, no admin pages.
  3. Share-settings check. "Anyone with the link" or "public" should be off in the builder, spreadsheet or file share, unless the app meets Floor 2.

  4. Search every file for keys. Keys usually sit in a JavaScript file, not the page, so searching one file isn't enough.

    • In the browser. Open the developer tools (F12, or Cmd+Option+I on a Mac), press Ctrl+Shift+F (Cmd+Option+F) to search all files, then reload and visit each screen so every file loads. Search for each pattern in the table below.
    • On the code. If you can export the code or have the build folder (often dist or build), run this from inside that folder:
    Get-ChildItem -Recurse -File -ErrorAction SilentlyContinue | Select-String -Pattern 'sb_secret_|service_role|sk_live_|rk_live_|sk-[A-Za-z0-9_-]{20,}|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|ghp_[A-Za-z0-9]{36}|github_pat_|xox[abpr]-|PRIVATE KEY|eyJ[A-Za-z0-9_-]{20,}\.' | ForEach-Object { "$($_.Path):$($_.LineNumber): $($_.Matches[0].Value)" }

    grep -rEno 'sb_secret_|service_role|sk_live_|rk_live_|sk-[A-Za-z0-9_-]{20,}|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|ghp_[A-Za-z0-9]{36}|github_pat_|xox[abpr]-|PRIVATE KEY|eyJ[A-Za-z0-9_-]{20,}\.' .
    If you find It usually is What to do
    sb_secret_, service_role, sk_live_, rk_live_, sk-…, AKIA…, ghp_ or github_pat_, xox…-, PRIVATE KEY A secret key (a backend service-role key, a payment, AI, cloud, code-host or chat key, or a private key) Stop sharing the app and follow if a key leaks
    eyJ… (a signed token) or AIza… Could be public (an anonymous database key, a web config key) or secret (a service-role token, an AI service key) Send it to your technical reviewer, who decodes it on their own machine and checks the role or scope
    sb_publishable_, pk_live_ Public by design Safe only if the data rules are on (step 5)

    Never paste a key into an online decoder or an AI chat. Finding nothing proves only that these patterns aren't there: keys come in other formats, and some files load only after sign-in. At Important and above, the technical reviewer also runs a full secret scanner.

  5. Ask the database directly, the way an attacker would: with only the public key and no sign-in. First add a test row to the table, because an empty table gives the same empty answer whether it's protected or open. Each command asks for one row at most.

    Type curl.exe, not curl: in Windows PowerShell, curl is a different command and these options fail.

    curl.exe "https://YOUR_PROJECT_HERE.supabase.co/rest/v1/YOUR_TABLE_HERE?select=*&limit=1" -H "apikey: YOUR_PUBLIC_KEY_HERE"
curl.exe "https://YOUR_PROJECT_HERE-default-rtdb.firebaseio.com/.json?shallow=true"

    curl "https://YOUR_PROJECT_HERE.supabase.co/rest/v1/YOUR_TABLE_HERE?select=*&limit=1" -H "apikey: YOUR_PUBLIC_KEY_HERE"
curl "https://YOUR_PROJECT_HERE-default-rtdb.firebaseio.com/.json?shallow=true"

    The first line is for a PostgreSQL-style REST backend (Supabase, for example); the second is for Firebase Realtime Database (newer projects may use a firebasedatabase.app address).

    • Closed: a permission error, or [] from a table you know holds a test row.
    • Open: any row of data. For Firebase, a list of keys, or null, which means open but empty.

    This checks reads only. Your technical reviewer adapts it for other backends (Firestore, storage buckets) and checks, on a test copy, that inserts, updates and deletes are refused too.

  6. Run the platform's checker, then book the external scan. Many platforms ship a security advisor that flags open tables and guest access; for CRM customer portals, a security firm's free scanner finds over-permissive guest profiles4. It's a backstop, not a replacement for steps 1–5. Then IT (or the technical reviewer it delegates to) runs a scheduled exposure scan from outside the network (monthly; required from Important per the gate matrix, and good practice for Team apps), and someone named reads the result. A passive or baseline scan can't find missing data rules or keys in the bundles, so the scan must run the checks in what the exposure scan must check. Against production, keep to read-only requests; run anything that submits forms or writes data against a test copy, after checking the platform's testing policy.

If any step fails, stop sharing the app and go to if your data was exposed.

How do API keys and secrets leak in AI-built apps?

A secret is anything that proves who an app is: API keys, passwords, database connection strings, OAuth client secrets and access tokens. Whoever holds it can do whatever it allows. This is the site's canonical guidance on secrets: how to follow never-do 2 (never put keys, passwords or tokens in an app's code, front end or prompts).

Where do secrets leak?

Where How it happens What stops it
The front end The AI tool puts a secret key in browser code so a feature "just works" Server-side functions hold the key; the key search in step 4
Prompts and chat history A builder pastes a config or .env file into an AI chat, and the secret now sits in the provider's logs Use placeholders such as YOUR_API_KEY_HERE; rotate any key you pasted
Code repositories A key committed "for now" stays in the history after it's deleted Secret scanning before every commit and on the repository
AI coding tools on a laptop Malicious code on the machine drives installed AI tools to hunt for secrets See coding agents
Logs and error messages The app logs a full request, including the token Log the event, never the secret; see logging

Don't: put secrets in prompts, repos or front ends (AP11)

The February 2026 exposure leaked third-party AI service keys along with the database11. In August 2025, a compromised build package drove installed AI command-line tools, with their permission-skipping flags, to search machines for credentials: more than 1,000 GitHub tokens leaked and more than 5,500 private repositories were made public15. In one vendor's 2025 study, repositories with an AI coding assistant active leaked secrets more often (6.4%) than the baseline (4.61%), a correlation, not proof of cause14. Once a secret has been in a prompt, a commit or a page, treat it as public and rotate it.

What should you do instead?

  1. Hold every secret server-side on your paved road: in a secrets manager (a cloud provider's secrets service, for example AWS Secrets Manager or Azure Key Vault, a dedicated vault, or a team password manager's secrets feature), or in the hosting platform's server-side secret store (its "environment variables" or "secrets" screen). A platform secret store qualifies, including for standard downgrade 3, only if all four hold: the value is never sent to the browser or bundled into client code; only the app's admins can read or change it; it can be rotated without a code change; and the app record names where it lives. A secret in source code, client-side config or a shared document never qualifies.
  2. Give each app its own scoped credential. Read-only where possible, one app per key, never a person's own login. If the tool can't scope a token, the app is tiered for everything the token can do unless standard downgrade 3 applies, and that downgrade requires the token to be held as in item 1. It isn't available to agents or AI features.
  3. Scan for secrets automatically. Turn on the repository host's push protection or secret scanning, and run an open-source scanner such as gitleaks or TruffleHog before each commit and on a schedule. Builders on AI app builders without a repository should repeat the key search in step 4 after every publish.
  4. Rotate on a schedule and on every leak. Prefer short-lived tokens. Rotate long-lived keys at least yearly, immediately when a key appears anywhere it shouldn't, and when a builder leaves (in the order on when the builder leaves: new secrets first, revoke the old ones when the leaver's access is removed).
  5. Record every credential in the app record. Record what it is, what it can do, where it's stored and who owns it, so it can be revoked at retirement.

What if a key leaks?

Revoke it first, then issue a new one, then check the provider's logs for use since the leak. Deleting the commit or the message doesn't un-leak it.

What should you do if your data was exposed?

Not legal advice

Not legal advice; as of October 2026. Written with an AI legal-research persona, not reviewed by a lawyer for your situation; your counsel decides whether a notice is owed. Every US state has a breach-notification law, with different triggers and deadlines; California's is 30 days16. Sector rules add their own clocks: the HIPAA breach rule for health data, the GLBA Safeguards Rule's notice to the FTC for non-bank financial institutions, the SEC's amended Regulation S-P for brokers and investment advisers, and Form 8-K for listed companies. In Canada, PIPEDA requires a report when a breach creates a real risk of significant harm, and a record of every breach kept for 24 months, where PIPEDA applies17; Alberta's PIPA has its own mandatory notice to its Commissioner on the same test (s. 34.1)18; Quebec requires notice of confidentiality incidents that risk serious injury, plus an incident register19. The GDPR's 72-hour notice applies only if the GDPR applies to you20. Who each duty covers, and its deadline, is on breach and incident duties.

  1. Save the evidence, then contain it. Before you change anything else, export the platform's access and API logs and screenshot the settings as you found them; some platforms keep access logs only briefly. Then turn off public access, close the share link or take the app offline. Don't delete the table, the bucket or the app.
  2. Rotate any secret that was reachable.
  3. Report it as an incident the same day. Follow incident response and bring in your privacy owner or counsel. Whether a notice is owed often turns on whether anyone accessed or took the data, which only the logs can show, so don't decide on your own that "nobody saw it".
  4. Record it in the registry. If the exposure broke Floor 2 by mistake, the floor-breach rule applies: record the as-found answer, set a fix-by date no more than 5 working days away, and confirm the fix with a clean exposure scan.
  5. Find the twins. If one app was open because of a platform default, others on the same platform probably are too. Scan them all.

Questions to ask your counsel

  • Who decides whether a notice is owed, and by what deadline?
  • Which logs and records must we keep after an exposure, and for how long?
  • Which states' and provinces' laws apply, given where the affected people live?
  • When must we tell the platform vendor, our insurer or a regulator?

Assumptions and evidence

  • A-015 (Medium): we expect most exposures of worker-built apps to be default or configuration errors that a fail-closed paved road prevents; test this by classifying the root cause of every exposure your scans and incidents find for two quarters.
  • A-014 (High that it happens; Low on the rate): we expect that, without platform defaults, a meaningful share of apps built on AI app builders will expose data; test this by scanning every registered app on the paved road and comparing the share with findings outside it. Don't quote a single exposure rate as fact.
  • A-025 (Medium): we expect the building platform itself to fail now and then, and every app on it to inherit the failure; test this by tracking your approved platforms' incident histories at each tool review.

Evidence: security-vendor research, a CVE record, news reports, vendor post-mortems and statutes; no controlled studies, and no public case of financial loss from a worker-built app. Facts on this page are as of October 2026.

  1. Escape, "The state of security of vibe-coded apps" (landing page; undated; about 1,400 apps; sampling method partly described). https://escape.tech/state-of-security-of-vibe-coded-apps [vendor], accessed 2026-10-21. ↩

  2. UpGuard, research on Power Apps portals exposing about 38 million records, 23 Aug 2021. https://upguard.com/breaches/power-apps [vendor], accessed 2026-10-21. ↩↩↩↩

  3. SecurityWeek, "Misconfigured Firebase instances expose 125 million user records", Mar 2024. https://www.securityweek.com/misconfigured-firebase-instances-expose-125-million-user-records/ [news], accessed 2026-10-21. ↩↩↩

  4. Cloud Security Alliance, article on Salesforce misconfigurations exposing sensitive data. https://cloudsecurityalliance.org/articles/salesforce-misconfigurations-are-exposing-sensitive-data [news], accessed 2026-10-21. ↩↩↩↩

  5. The Hacker News, report of threat actors mass-scanning Salesforce Experience Cloud sites, Mar 2026. https://thehackernews.com/2026/03/threat-actors-mass-scan-salesforce.html [news], accessed 2026-10-21. ↩

  6. Wiz Research, "Wiz Research uncovers exposed DeepSeek database leaking sensitive information", 29 Jan 2025. https://www.wiz.io/blog/wiz-research-uncovers-exposed-deepseek-database-leak [vendor], accessed 2026-10-21. ↩↩

  7. Tenable, CVE-2025-48757 record (published 30 May 2025; the vendor disputes it). https://www.tenable.com/cve/CVE-2025-48757 [primary], accessed 2026-10-21. ↩↩↩↩

  8. Wiz Research, "Critical vulnerability in Base44", Jul 2025. https://www.wiz.io/blog/critical-vulnerability-base44 [vendor], accessed 2026-10-21. ↩

  9. CyberInsider, report on the Tea app data breach, 25 Jul 2025. https://cyberinsider.com/tea-app-suffers-data-breach-exposing-72000-users-photos-and-private-messages/ [news], accessed 2026-10-21. ↩

  10. 404 Media, report on an AI chat app leaking users' conversations, Jan 2026. https://www.404media.co/massive-ai-chat-app-leaked-millions-of-users-private-conversations/ [news], accessed 2026-10-21. ↩

  11. Wiz Research, "Exposed Moltbook database reveals millions of API keys", 2 Feb 2026. https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys [vendor], accessed 2026-10-21. ↩↩↩

  12. Lovable, "Our response to the April 2026 incident" (vendor post-mortem). https://lovable.dev/blog/our-response-to-the-april-2026-incident [vendor], accessed 2026-10-21. ↩↩

  13. OWASP ZAP, "Active Scan" documentation. https://www.zaproxy.org/docs/desktop/start/features/ascan/ [primary], accessed 2026-10-21. ↩

  14. GitGuardian, "The state of secrets sprawl 2025", Mar 2025. https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025/ [vendor], accessed 2026-10-21. ↩

  15. Wiz Research, "s1ngularity: supply chain attack", 26 Aug 2025. https://www.wiz.io/blog/s1ngularity-supply-chain-attack [vendor], accessed 2026-10-21. ↩

  16. Cal. Civ. Code §1798.82 (30 calendar days from 1 Jan 2026), https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.82 [statute]; NCSL, Security Breach Notification Laws, https://www.ncsl.org/technology-and-communication/security-breach-notification-laws [secondary index of statutes], accessed 2026-10-21. ↩

  17. PIPEDA ss. 10.1 and 10.3, https://laws-lois.justice.gc.ca/eng/acts/P-8.6/; Breach of Security Safeguards Regulations, SOR/2018-64 (records kept 24 months), https://laws-lois.justice.gc.ca/eng/regulations/SOR-2018-64/page-1.html [statute], accessed 2026-10-21. ↩

  18. Alberta Personal Information Protection Act, SA 2003, c. P-6.5, s. 34.1 (notice to the Commissioner "without unreasonable delay" where a reasonable person would consider there's a real risk of significant harm), https://kings-printer.alberta.ca/1266.cfm?page=P06P5.cfm&leg_type=Acts&isbncln=9780779855148 [statute; the text didn't render for our tools, so the wording is confirmed through the Alberta OIPC's practice note, https://oipc.ab.ca/resources/notifying-affected-individuals-practice-note.aspx, regulator], accessed 2026-10-21. ↩

  19. Act respecting the protection of personal information in the private sector, CQLR c. P-39.1, ss. 3.5–3.8, https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1 [statute], accessed 2026-10-21. ↩

  20. Regulation (EU) 2016/679 (GDPR), Art. 33, https://eur-lex.europa.eu/eli/reg/2016/679/oj [statute], accessed 2026-10-21. ↩