The vibe-coder's launch checklist

The security checks to pass before you launch.

16 checks, in plain English, for an app built with AI. Each one maps to a real mistake these tools make again and again — and each is something you can verify against your own code and live site today.

Run the whole checklist automatically How to evaluate an app

Reviewed October 23, 2026 · Updated October 23, 2026

How to read the checklist

Not every box weighs the same. One kind blocks launch outright.

This is the exact weighting SafeLaunch uses to turn findings into a verdict. We're showing it so the checklist is honest about what's urgent and what can wait — a score with no critical issues and 80+ out of 100 is “safe to launch.”

Critical−30

Any single critical issue = do not launch

High−12

Fix before you put it in front of real users

Medium−5

Fix soon — these add up

Low−1

Good hygiene; clean these up when you can

The checklist

16 checks, across seven areas.

Work top to bottom. Each item is derived from a check SafeLaunch runs on real AI-built apps — grouped so you can hand a whole section to whoever maintains that part.

Secrets & keys

A leaked key is the fastest way to lose money or data — anyone who finds it can act as you.

No live API keys hard-coded in your filesCritical
Stripe, OpenAI, Anthropic, AWS, GitHub, Google, Slack tokens and private keys belong in environment variables read only on the server — never pasted into code.
No real .env file committed to the repositoryCritical
Environment files hold your passwords and keys. Once committed they stay in the repo's history even after you delete them. Keep a .env.example with placeholder values instead.

Database & access rules

The single most common serious gap in AI-built apps: a database anyone with the public key can read.

Row-level security is turned on for every tableHigh
Without it, anyone holding your public database key — which every visitor's browser has — may be able to read or change every row, including other users' data.
The service-role (master) key is used only on the serverCritical
The database master key bypasses every security rule. If it appears in browser code or a NEXT_PUBLIC_ variable, anyone can read, change or delete all your data.

Hidden & malicious code

Code you can't see is code you can't trust — these patterns are how real-world supply-chain attacks hide.

No obfuscated code hidden in your filesCritical
Code pushed far off-screen behind a wall of spaces, or built from eval / remote loading, is a known malware pattern. It typically runs on every build and can steal your secrets.
No install scripts that download or run commandsHigh
A preinstall/postinstall script that runs curl, wget or a shell command executes automatically whenever the project is installed — a common way malware spreads.

Dependencies

You inherit the security of every package you install. Known holes are public — attackers scan for them.

No dependencies with publicly known vulnerabilitiesHigh
Your package versions are checked against the OSV database of known vulnerabilities. Running a version with a published advisory is an open door attackers actively look for.

Your live site

The outside-in checks: what anyone on the internet can see and reach without logging in.

Served over HTTPS, with http redirected to httpsHigh
Without HTTPS, passwords and personal data travel unencrypted and can be read on public Wi-Fi. Browsers also warn visitors away.
Security response headers are setMedium
A Content-Security-Policy, HSTS and X-Content-Type-Options header blunt whole classes of injection and downgrade attacks. Most AI-built sites ship without them.
Pages can't be silently embedded by other sitesLow
Framing protection (X-Frame-Options or a frame-ancestors policy) stops another site loading yours invisibly to trick users into clicking — clickjacking.
No secret files are downloadable on your domainCritical
A .env or .git/config left reachable on your live site hands over your keys and full source history to anyone who guesses the URL.

AI & data flow

If your app uses AI, user data leaves your walls — know where it goes, and don't let the model be steered.

You know which AI providers receive user dataLow
User text sent to a model leaves your app for that provider's servers — which may be in another country. Your privacy policy should say so, and it should match your users' expectations.
Features that feed user text to AI are tested against prompt injectionLow
Any box where a user's words become part of an AI prompt can be used to hijack the model. Add input limits and a system prompt that refuses instructions hidden in user content.
No model files in formats that can run codeHigh
Pickle-based model files (.pkl, .pt, .pth, .ckpt) can execute arbitrary code when loaded. A model from an untrusted source in this format can compromise your server.

Launch basics

The quiet housekeeping that stops an avoidable mistake the week after you ship.

Your .gitignore excludes .env filesMedium
Without the rule, the file holding your keys can be committed by accident the next time you save your work. Add .env, .env.local and .env*.local.
A privacy policy is in place (if you collect personal data)Low
If your app collects emails, accounts or any personal data you need a privacy policy before launch — and app stores and payment providers require one.

Don't want to run all 16 by hand?

SafeLaunch checks your repo and live site against every item here in about 30 seconds — and hands you the fix for each one.

Scan my app

Why the list isn't optional

Each item here is a real incident waiting to happen.

Two that already did — both trace back to a single box on this list that nobody ticked before launch. Figures are from public reporting and the NVD; see Sources below.

July 2025 · Tea app

~72,000 private images exposed from an open bucket

A storage bucket was left reachable on the public internet; private images, including identity photos, were downloaded and spread. That's the “no secret files / data downloadable” and access-rules checks, failed.

Source: public reporting, July 2025. Checked Oct 23, 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, letting unauthenticated users read or write arbitrary tables. The vendor disputes it, arguing data rules are the customer's job — which is exactly why the row-level security check is on your list, not theirs.

Source: NVD (disputed by vendor). Checked Oct 23, 2026.

Why one smart attacker is now a swarm of agents →·The full evaluation guide →

Builder-agnostic

The same list, whatever you built with.

Lovable, Bolt, Cursor, v0, Replit, Claude Code — they differ on speed and feel, and we take no position on that. But a leaked key, an open database or a downloadable .env looks identical whichever tool wrote it, so the checklist doesn't change.

Works with any builder — the checks don't change
Verified against your real repo and live site, not marketing
One independent verdict — no builder grades its own work

The neutral layer

LovableBoltCursorv0ReplitClaude Code…

Viberrr — independent trust layer

Runs the checks · issues the seal

Sources & citations

Everything load-bearing, linked.

The standards behind each check, the database we scan dependencies against, and the incidents that show why it matters. Each checked on the date shown.

[1]OWASP Top 10
The category mapping behind the access-control, vulnerable-components and misconfiguration checks.
Checked Oct 23, 2026
[2]CWE — Common Weakness Enumeration
CWE-798 (hard-coded credentials), CWE-863 (incorrect authorization) and CWE-506 (embedded malicious code).
Checked Oct 23, 2026
[3]OSV — Open Source Vulnerabilities
The database used to check your dependencies against publicly known vulnerabilities.
Checked Oct 23, 2026
[4]NVD — CVE-2025-48757
Insufficient database row-level security in Lovable-generated apps (CWE-863, published 2025-05-29; disputed by the vendor).
Checked Oct 23, 2026
[5]Tea breach — public reporting
Coverage of the July 2025 Tea incident and the ~72,000 images exposed from an unsecured storage bucket (Tom's Guide).
Checked Oct 23, 2026
[6]OWASP — LLM prompt injection
The risk behind the prompt-injection check for any feature that feeds user text into an AI model.
Checked Oct 23, 2026

Questions

Before you ship.

What should I check before launching a vibe-coded app?

Work through the 16 checks on this page across seven areas: leaked keys and committed secrets, database access rules (row-level security), hidden or malicious code, vulnerable dependencies, your live site (HTTPS, security headers, exposed files), AI data flow and prompt injection, and launch basics like .gitignore and a privacy policy. Run each against your own repository and live site — not the builder's marketing.

What's the difference between a critical and a low issue?

A critical issue — a leaked key, an exposed database master key, hidden code, a downloadable .env — can be exploited directly and means do not launch until it's fixed. High issues should be fixed before real users arrive; medium and low are hygiene that add up. It's the same weighting SafeLaunch uses to decide whether an app is safe to launch.

Can I run this checklist myself?

Yes. Every item is something you can verify by hand against your code and live site. SafeLaunch automates the whole list in about 30 seconds and explains each finding in plain English with a fix — and because it's independent, the verdict doesn't come from the party that built the app.

Does passing this checklist mean my app is completely secure?

No. These are the common, high-impact security mistakes AI builders make repeatedly — the ones that end up in the news. Clearing them removes most of the real-world risk, but an automated check is not a guarantee or a full manual security audit, and it can't judge business logic unique to your app.

Ready when you are

Run all 16 checks in about 30 seconds.

SafeLaunch checks your repo and live site against every item on this list, explains each finding in plain English, and hands you the fix.

Scan my app