A claim is not a check
A "secure" label you (or your builder) print is a claim about intent. A scan is a test against the running code and live site. Only one of them can be wrong in a way an attacker finds.
The vibe-coder's evaluation guide
How to evaluate a vibe-coded app before you trust it.
A neutral, cross-builder reference for deciding whether an app built with AI is actually safe — including the one dimension most comparisons skip. Published by a security company, with its bias disclosed, and sourced where it matters.
Reviewed October 22, 2026 · Updated October 22, 2026
Our stance, stated plainly
We publish this. We also sell the scan. Here's the bias.
This guide is written by Viberrr, an independent security and trust layer for AI-built apps. We make money when people scan — so treat the framing with that in mind. We think it holds up anyway.
We do not benchmark builders on speed, cost or output quality, and we don't claim any specific builder is insecure. The safety evaluation is the same whoever you built with.
Claims here are sourced where possible, and dated. Where we don't have evidence, we say so instead of reaching for a number.
Most important: documentation describing a security capability does not establish that your app is safe. That's the gap this whole page is about.
The principle
A scan beats a badge you print yourself.
The same way a test beats a feature score: trust isn't what you say about your app, it's what holds up when someone independent checks.
Independence is the point
The party that built the app has every incentive to call it safe. An evaluation worth trusting is run by someone who doesn't benefit from the verdict.
Documentation ≠ your app
A builder's docs describing a security capability tell you the capability exists. They do not tell you it's switched on, configured correctly, or present in your particular app.
The framework
The dimensions to actually test.
Four questions decide whether the app works and will last. A fifth — the one most “compare the builders” pages leave out — decides whether it's safe to put in front of real people.
Functionality & workflow
01 · Functionality- What it is
- Does the core job actually work, end to end — not just the happy-path demo the builder showed you?
- How to test it
- Run the real task a user would: sign up, do the main action, hit an edge case, come back the next day. Try to break it with empty inputs and the back button.
- Why it matters
- AI builders are fluent at generating screens that look finished but fall apart on the second click. A demo is not a workflow.
Data & export / ownership
02 · Ownership- What it is
- Can you get your (and your users') data out, and do you actually own the code and the database?
- How to test it
- Export your data to a file. Find the repository and the database — confirm you can reach both without the builder's dashboard. Ask: if this tool shut down tomorrow, do I still have everything?
- Why it matters
- Trust includes being able to leave. An app you can't export from or self-host is an app you don't fully control.
Payments & billing
03 · Money- What it is
- If the app takes money, does it do it correctly — right amounts, real receipts, no way to bypass the paywall?
- How to test it
- Run a test payment end to end. Try to access paid features without paying. Check that prices and totals are computed on the server, not just shown in the browser.
- Why it matters
- Payment logic that lives only in the frontend can be edited by anyone with developer tools open. That is a direct financial risk.
Handover & running cost
04 · Handover- What it is
- Can someone else run and maintain this, and what will it cost to keep alive each month?
- How to test it
- List every paid service it depends on (hosting, database, AI APIs, email). Add up the monthly cost. Confirm a second person could deploy a change from the repo alone.
- Why it matters
- A free-to-build app with surprise running costs, or one only its original author can touch, is a liability dressed as an asset.
05 · The dimension others skip
Security & trust
Whether the app leaks secrets, exposes its database, ships vulnerable or hidden code, leaves its live site open, or quietly sends user data somewhere you didn't agree to. This is the dimension a feature-comparison table can't cover — and the one that ends up in the news when it's wrong.
How to test it: run each check below against your own repository and live site — not the builder's marketing. Each maps to a public standard so you can verify what it means.
CWE-798
Leaked keys & secrets
Stripe, OpenAI, AWS, GitHub and database master keys in code or committed .env files.
OWASP A01
Open databases / missing access rules
Supabase tables without row-level security, and admin keys shipped to the browser.
CWE-506
Hidden / malicious code
Obfuscated scripts tucked into config files that run every time you build.
OWASP A06 · OSV
Vulnerable dependencies
Packages with publicly known security holes, checked against the OSV database.
OWASP A05
Live-site exposure
HTTPS, security headers, and secret files left downloadable on your domain.
AI inventory
Where user data goes
Which AI providers receive user data, and unsafe model files in the repo.
Why this dimension isn't optional
Two real incidents, not hypotheticals.
Both come down to a check on the security dimension that nobody ran before launch. Figures are from public reporting and the NVD — see Sources below.
July 2025 · Tea app
~0 images exposed from an unsecured bucket
A legacy storage bucket was left reachable on the public internet. Private images — including identity photos — were downloaded and spread. This maps directly to publicly readable storage (OWASP A01).
Selfies & photo IDs13,000
Posts, comments & message images59,000
| Selfies & photo IDs | 13,000 |
|---|---|
| Posts, comments & message images | 59,000 |
Source: Tea's public statement, as reported July 2025 (Tom's Guide, Bitdefender). Figures are the company's own; independent estimates vary. Checked Oct 22, 2026.
May 2025 · CVE-2025-48757
Missing database access rules in AI-generated apps
The NVD entry describes insufficient row-level security in Lovable-generated apps through 2025-04-15, letting unauthenticated users read or write arbitrary tables. Public reporting put the scope at 170+ apps. The vendor disputes the entry, arguing customers are responsible for their own data rules — which is exactly why an independent check on your app matters.
- Weakness
- CWE-863 (Incorrect Authorization)
- Maps to check
- Open databases / missing RLS (A01)
- Published
- 2025-05-29 (NVD)
- Status
- Disputed by vendor
Source: NVD entry for CVE-2025-48757; scope figure from public reporting. Checked Oct 22, 2026.
What we see in real scans
Our own data, honestly held to a threshold.
From SafeLaunch scans of real AI-built apps. Aggregate and anonymized; we only publish rates once the sample is large enough to be honest.
0
Apps scanned
0%
Shipped ≥1 issue
0%
Passed clean
0
Findings logged
Vulnerable dependencies303
Database access (RLS)180
Launch basics174
Where your data goes (AI)54
Leaked keys & secrets36
Live-site hardening13
Critical3%High49%Medium23%Low25%
Aggregate SafeLaunch telemetry, updated October 23, 2026. See the full data report →
Where builders fit
Whatever you built with, the safety check is the same.
Lovable, Bolt, Cursor, v0, Replit, Overskill, Claude Code — they differ on speed, price and feel, and we take no position on that. But a leaked key, an open database or a missing access rule looks identical whichever tool wrote it.
And the safety verdict isn't something a single builder can neutrally certify about its own output. That's the layer Viberrr sits in: independent, cross-builder, running the same evaluation and issuing the seal — so the trust comes from a test, not a logo.
- Works with any builder — the checks don't change
- No builder certifies its own output here
- One verdict, independently issued
The neutral layer
LovableBoltCursorv0ReplitClaude CodeOverskill…
Viberrr — independent trust layer
Runs the checks · issues the seal
Sources & citations
Everything load-bearing, linked.
The incidents, the standards behind each check, and the databases we scan against. Each checked on the date shown.
Insufficient database row-level security in Lovable-generated apps (CWE-863, published 2025-05-29; disputed by the vendor).
Checked Oct 22, 2026
Coverage of the July 2025 Tea incident and the ~72,000 images exposed from an unsecured storage bucket (Tom's Guide).
Checked Oct 22, 2026
Independent write-up of the same incident and the image breakdown (Bitdefender).
Checked Oct 22, 2026
- [4]OWASP Top 10
The category mapping behind the access-control (A01), vulnerable-components (A06) and misconfiguration (A05) checks.
Checked Oct 22, 2026
CWE-798 (hard-coded credentials) and CWE-506 (embedded malicious code), used for the secrets and hidden-code checks.
Checked Oct 22, 2026
The database used to check dependencies against publicly known vulnerabilities.
Checked Oct 22, 2026
Questions
Is my vibe-coded app safe?
How do I know if my vibe-coded app is safe?
You evaluate it across the dimensions that matter — does it work, can you own and export the data, does it handle money correctly, can someone else run it — and, critically, whether it's secure: no leaked keys, no open database, no missing access rules, no vulnerable or malicious dependencies, and a hardened live site. Reading the builder's documentation is not the same as testing your actual app.
Does using a reputable AI builder mean my app is secure?
Not by itself. The builder generates code; the safety of the specific app you shipped depends on how it was configured and what you added. A builder can't neutrally certify its own output, and documentation that a capability exists doesn't prove it's enabled in your app.
Why can't the builder just tell me it's secure?
Because it has an incentive to say yes, and because "secure" is a property of the running app, not of the tool that wrote it. Independent verification exists precisely so the verdict doesn't come from the party that benefits from it.
What's the single most common security mistake?
Leaked secrets — live API keys pasted into frontend code or committed to the repo — and databases shipped without access rules, so anyone with the public key can read other users' data. Both show up again and again across every builder.
Ready when you are
Scan my appRun the security dimension in about 30 seconds.
SafeLaunch checks your repo and live site against every item above, explains each finding in plain English, and hands you the fix.