← The AI Hype Audit — all 115 verdicts
HOLDS UP “99% of vibe-coded apps are missing these security basics” — the rare claim that checks out
The claimVibe-coded apps ship with a handful of security basics missing, and that gap causes the majority of their security problems — check your app before you ship it. (“How many does your app have?” / “Did I miss anything?”)
This one holds up — it's anti-hype content pointing at a documented problem. Carnegie Mellon research found roughly 61% of AI-generated code is functionally correct but only about 10.5% is secure, and the pattern is well explained: AI coding tools optimize for the functional goal you state, and security is a non-goal unless you make it one. The documented breach list for vibe-coded apps repeats the same few failures — exposed secrets, missing authorization checks, no rate limiting, unvalidated input — none requiring a sophisticated attacker. TikTok blocked extraction of this video's exact on-screen list, so the Medium confidence is only about whether this creator's specific items are the canonical ones; the claim itself is settled. The definitive checklist is in the steps below — it's assembled from documented breaches and OpenSSF guidance, not from anyone's course.
What holds up
- Research-backed: AI-generated code is mostly functional but rarely secure by default (CMU: ~61% correct, ~10.5% secure)
- The failure modes are documented from real breaches — secrets, auth checks, rate limits, input validation
- A security-focused rules file measurably reduces vulnerabilities in generated code — OpenSSF recommends exactly this
- No funnel detected — the creator appears to just be sharing the checklist
What doesn't
- The video's exact on-screen list couldn't be extracted (TikTok blocks it) — the specific items are unverified
- A checklist covers the basics that killed real apps; it does not replace a pentest once you hold real user data
The catch
The uncomfortable part isn't in the video — it's that the fix is boring and free. A permanent security rules file in your repo (CLAUDE.md / AGENTS.md / .cursorrules) makes the AI write secure code by default, and almost nobody bothers. The gap between 61% functional and 10.5% secure is the space where every vibe-coded-app breach story lives.
How to actually do it
- 1. SECRETS — no API keys in client-side code, no exposed .env, none in git history. A leaked key is a master key; attackers run up your API bill first
- 2. AUTHORIZATION on every endpoint — change an ID in the URL: can user A pull user B's data? (IDOR — the most common vibe-code hole)
- 3. SERVER-SIDE rules — if using Supabase/Firebase, enforce Row Level Security; client-side checks are decoration
- 4. RATE LIMITING on login and every costly endpoint — stops brute force and bill-burning
- 5. INPUT VALIDATION everywhere user text renders or hits a query — XSS and injection
- 6. DEPENDENCY AUDIT — npm audit / pip audit in CI, five minutes to set up, runs forever
- 7. PREVENTION LAYER — commit a security rules file (CLAUDE.md / AGENTS.md) so every future generation starts secure; see OpenSSF's guide and the open-source vibe-check repo (github.com/benavlabs/vibe-check, 17 documented vulnerability checks)
- 8. Once you have real users and real data: hire a pentester. No checklist replaces someone actively trying to break your app
Built the definitive version of what the video points at: the pre-ship security checklist for vibe-coded apps, below — plus the prevention layer (a rules file) that stops the holes from being written in the first place.
- Confidence
- Medium
- Posted by
- a build-in-public app developer posting vibe-coding security content — no visible funnel, which is rare
We test hype for free. We build the real thing for a living.
Thirty minutes, no pitch — and you'll leave with something useful either way.
Book a call with Todd or start with the free Business Checkup →The Verdict Weekly
Three verdicts every Friday. Free forever, unsubscribe anytime, no spam — that would be ironic.
© Schreier Group · schreiergroup.com · See a wild AI claim? Drop it here and we'll test it.