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.
AI tools write working code quickly, and they tend to leave the same gaps every time. This page lists those gaps, the public reports behind each one, what you can check yourself tonight, and when it makes sense to pay a person to look.
The risks that keep showing up
- 01
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.
- 02
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.
- 03
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.
- 04
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.
- 05
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.
- 06
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.
- 07
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.
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
- 01
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.
- 02
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.
- 03
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.
- 04
Try the plain http address
Type your address with http instead of https. It should move you to https straight away.
- 05
Check the packages you added
Paste your package file into the package checker 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.
Questions people ask
- 01
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.
- 02
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.
- 03
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.
- 04
How long does the free check take?
About twenty seconds. It needs only your public address and no account.
See which of these risks your app shows from the outside, in about twenty seconds.
ShipReady is not a penetration test or a security certification. No automated check can prove an application is secure.
Last updated October 25, 2026