https://shipreadyai.dev/vibe-coding-security-risks

> Discover all available pages from the documentation index at https://shipreadyai.dev/llms.txt

# Vibe coding security risks

The most common vibe coding security risks are database tables anyone can read, server keys left in the code your visitors download, admin pages with no sign-in, weak sign-in flows and missing protective headers. Most of them can be spotted from outside in about twenty seconds. The rest need someone to look inside the app.

## The risks that keep showing up

- **Database tables anyone can read**
  The app's browser key is meant to be public, but it only stays harmless when every table has row rules. When rules are missing, anyone holding the key can read rows they should never see. Reports name 170 production apps built with Lovable with broken access control, tracked as CVE-2025-48757. See the [write-up and sources](/incidents/lovable-cve-2025-48757).
- **Server keys inside the code visitors download**
  A key meant for the server ends up in the JavaScript every visitor's browser loads. Anyone can open it and use it. One study of 5,600 vibe-coded apps reported more than 400 exposed secrets. See the [write-up and sources](/incidents/five-thousand-six-hundred-apps-scanned).
- **Admin pages with no sign-in in front**
  An admin route that answers anyone turns a small mistake into a large one. One app exposed 4.75 million records, including 1.5 million API tokens, through missing access rules and an open admin route. See the [write-up and sources](/incidents/moltbook-records-exposure).
- **Sign-in that can be skipped or tricked**
  Sign-in logic lives inside the app, so it fails quietly. A platform-wide sign-in flaw at Base44 allowed access to private enterprise data. See the [write-up and sources](/incidents/base44-auth-flaw).
- **Missing protective headers**
  Headers tell browsers what the page may load, whether it may be framed by another site, and to always use https. AI tools rarely add them. They are cheap to fix and easy to forget.
- **Public source maps and leftover files**
  Source maps hand anyone a readable copy of your code. Leftover environment files, backups and debug pages do the same with settings.
- **Packages that do not exist**
  AI tools sometimes suggest package names that were never published, and someone can register that name later with harmful code. Read more in the [glossary entry on slopsquatting](/glossary/slopsquatting).

## Which risks an outside check can see

| Risk | What the free check can say |
| --- | --- |
| Tables that answer the browser key | Observed, with table names and counts, never row contents |
| Server keys in client code | Observed, with the evidence line |
| Admin and other exposed paths | Observed when they answer from outside |
| Missing headers, source maps, https | Observed, with the response that proves it |
| Whether each row rule is correct | Not verified, a URL cannot read it |
| Sign-in and password reset logic | Not verified, it needs a person inside the app |
| Payment webhooks and refunds | Not verified, it needs a person inside the app |

## What you can check yourself tonight

- **Search your built code for key names**
  Open your live site, view the loaded JavaScript, and search for words like secret, service_role and sk_live. Anything meant for a server should not be there.
- **Sign in as a second account**
  Make a second test account and try to open the first account's pages and records. If you can see anything that is not yours, the row rules need work.
- **Visit your admin address while signed out**
  Open every admin or dashboard address in a private window. Each one should send you to sign-in.
- **Try the plain http address**
  Type your address with http instead of https. It should move you to https straight away.
- **Check the packages you added**
  Paste your package file into the [package checker](/tools/package-check) and confirm every name is real and widely used.

## When to get a person to look

- Your app stores other people's data behind sign-in.
- Your app takes payments, or will within the month.
- You plan to send real users to it within 30 days.
- You never read the row rules your AI tool wrote.

If any of these is true, a [Launch Review](/launch-review) puts a person on the parts a URL cannot reach: row rules, sign-in flows and payment handling. You get a written list of what to fix first.

## Questions people ask

- **Is vibe coding risky?**
  The code is not worse because a tool wrote it, but it is usually shipped before anyone reads it. The risks above are the ones that follow from that. Checking them before launch is what changes the outcome.
- **Are browser keys a leak?**
  No. Publishable and anon keys are meant to be public. They only become a problem when the tables behind them have no row rules.
- **Can a scan prove an app has no problems?**
  No. An outside check reports what it observed and lists what it could not verify. It cannot prove an app is free of problems, and ShipReady never shows a score.
- **How long does the free check take?**
  About twenty seconds. It needs only your public address and no account.