Late January 2026. A developer ships a social network over a weekend. No traditional code written — just prompts, a vision, and an AI that turned ideas into a working product in days. The platform goes viral. Andrej Karpathy, OpenAI co-founder, calls it "the most incredible sci-fi takeoff-adjacent thing I have seen recently."
Then a security researcher opens the browser's developer tools.
Within minutes, they find an API key sitting in plain JavaScript — visible to anyone who knows how to press F12. They use it to query the production database. No login required. No special tools. Just a simple command and a coffee.
What comes back: 1.5 million API authentication tokens. 35,000 email addresses. Thousands of private messages. The entire platform — every agent, every credential, every conversation — sitting wide open.
The platform was called Moltbook. The fix, when it came, took two SQL statements.
This is not a story about a bad developer. It is a story about a gap that AI does not fill automatically — and what you can do about it before you ship.
The Illusion That Catches Everyone
A few years ago, building software required crossing a painful barrier. You had to learn syntax, frameworks, databases, APIs, Git, deployment — and break things repeatedly along the way. For most people outside tech, software engineering felt like a locked room with a very small door.
Then AI arrived.
Now someone with little traditional programming experience can build a SaaS app over a weekend, connect a database to a frontend, integrate payments, and deploy an API — all from prompts. That shift is extraordinary, and I think it is genuinely amazing. I am a vibe coder too. I understand the excitement of watching an idea move from imagination to a working product faster than ever before.
But there is a dangerous illusion forming around AI-generated software: If the app works, people assume it's safe. Those are not the same thing.
A beautifully designed application can still expose private user data, leak API keys, allow unauthorized access, and accidentally disable database protections — all while the UI looks polished and the login flow works perfectly. Security problems live underneath visible functionality. That is exactly what happened with Moltbook.
What AI Gets Right, and What It Quietly Skips
AI is very good at helping you build the happy path — the feature works, the button responds, the API returns data, the page renders. That part is genuinely impressive.
Security lives in the unhappy paths:
- What if someone queries your database without logging in?
- What if an attacker manipulates a request from the browser?
- What if your API keys are visible in the page source?
- What if someone calls your registration endpoint ten thousand times in a loop?
Experienced developers ask these questions automatically. Not because they are smarter — but because they built the habit slowly, over years of debugging painful issues, reading post-mortems, and making mistakes in lower-stakes environments.
AI compresses the implementation timeline dramatically. It does not compress the experience required to ask the right security questions. That gap is where breaches happen.
And to be clear: this is not only a beginner problem. Even experienced developers can become overconfident when AI accelerates output speed. Because AI-generated code often looks extremely convincing. The explanations sound confident. The architecture appears plausible. The feature functions correctly.
But plausible code is not the same as safe code.
The Moltbook Breakdown: What Actually Went Wrong
Moltbook was built on Supabase — a popular, well-documented backend service that is excellent for fast development. Supabase is designed to work with a public API key exposed on the client side. That is intentional and not, by itself, a security failure.
The security failure is what you configure that key to be able to do.
Supabase ships with a feature called Row-Level Security — a database setting that ensures users can only access their own data. It is not enabled by default. You have to turn it on. And if you are vibe coding and the AI generates a working backend without you asking about security, there is a good chance that step never comes up.
At Moltbook, it didn't.
The result: anyone with basic technical knowledge could query the entire production database — every user's credentials, private messages, and authentication tokens — using the key sitting in plain sight on the website. Write access was also open, meaning an attacker could have edited any post on the platform without logging in.
The founder's public statement captured the situation honestly: "I didn't write a single line of code for Moltbook. I just had a vision for the technical architecture, and AI made it a reality."
The AI made a working platform. It did not make a secure one.
It Is Not Just Moltbook
Six months before Moltbook, security researchers at Wiz found a critical vulnerability in Base44 — a vibe coding platform used by actual enterprises to build internal HR systems, customer databases, and knowledge bases containing sensitive employee data.
The flaw was shockingly simple: two API endpoints for registering and verifying users required no authentication whatsoever. Using only a value visible in the app's public URL, a researcher could create a verified account inside any private enterprise application on the platform — bypassing SSO and every other access control entirely.
Here is the detail that changes the conversation: Base44 builders did not write that vulnerable endpoint. The platform did. Individual developers had no visibility into the flaw. This is the second dimension of vibe coding security risk that almost nobody talks about. The first is what AI generates when you prompt it. The second is what the platform you are building on introduces independently of your code.
Both matter. Both can be addressed.
Security in Plain English
One reason security feels intimidating is because the terminology sounds abstract and technical. Most of it isn't. Here is a plain-English translation of the concepts that come up most often:
| Term | What It Actually Means |
|---|---|
| Authentication | Verifying who someone is |
| Authorization | Deciding what they are allowed to access |
| API Key | A secret password your app uses to talk to another service |
| Row-Level Security | Preventing users from reading other users' data in your database |
| Rate Limiting | Stopping someone from making thousands of requests in a loop |
| Secret Scanning | Automatically detecting exposed passwords or keys in your code |
| Least Privilege | Only giving a system the minimum access it actually needs |
| Input Validation | Making sure users can't send dangerous or unexpected data |
Security is not magic. Most of the time it is about reducing obvious mistakes, limiting damage when mistakes happen, and protecting user trust. That's it.
The Five Things AI Consistently Misses
These are the patterns that show up repeatedly in AI-generated code — not as exotic edge cases, but as defaults. Each one comes with a practical fix.
1. API Keys Exposed in Client-Side Code
When you ask AI to connect your app to an external service, it will often put the credentials directly in the frontend code. Frontend code is public. Anyone can open the browser's developer tools and find it. Automated scanners crawl the web looking for exactly this.
The fix: Run Gitleaks before you push code. It scans for secrets and blocks the commit if it finds any. GitHub's built-in secret scanning does the same thing automatically on public repositories — no setup required.
2. Row-Level Security Not Enabled
This is the Moltbook failure. AI can generate a complete Supabase schema without ever enabling RLS, because RLS requires understanding your data access model — who should see what — and AI often skips that reasoning unless you ask for it explicitly.
The fix: In your Supabase dashboard, check that RLS is enabled on every table containing user data. Then write policies that define exactly who can access each row. The Supabase documentation has a beginner-friendly walkthrough that takes about twenty minutes.
-- Enable RLS on a table
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;
-- Users can only read their own records
CREATE POLICY "owner_only"
ON agents FOR SELECT
USING (auth.uid() = owner_id);
3. API Endpoints With No Authentication
AI generates routes that respond to requests. Whether it adds authentication to those routes depends on whether you asked — and whether the AI remembered your earlier requirements by the time it got to that file.
The fix: Go through every API route and ask: what happens if someone calls this without logging in? Tools like Bearer scan your codebase and flag unprotected routes for free. Better still, apply authentication at the middleware layer so every route is protected by default.
4. Secrets on the Wrong Side of the App
Many AI tools know not to hardcode secrets and will suggest environment variables. What they sometimes miss is the difference between variables available to the client (public) and variables available only to the server (private).
In Next.js, any variable prefixed with NEXT_PUBLIC_ is bundled into the client JavaScript and visible to everyone. Your OpenAI API key, Stripe secret key, and database credentials should never have that prefix.
The fix: Search your project for NEXT_PUBLIC_ and verify that nothing sensitive uses it. Server-only secrets get no prefix. Public configuration values — like your Supabase URL — can use the prefix safely, but only if RLS is properly configured.
5. No Rate Limiting
AI generates endpoints that respond to requests. It does not add rate limiting unless you ask. This means your registration endpoint, login endpoint, and data endpoints will accept unlimited requests from anyone.
At Moltbook, this allowed a single bot to create 500,000 fake accounts. The same pattern can be used to exhaust your API quota overnight and run up a bill that ends your project.
The fix: If you are on Vercel, enable rate limiting in your project's security settings — it takes five minutes and requires no code. For Supabase, the same option exists under Project Settings. Do this before you go public.
The Mistake Almost Everyone Makes: "I'll Secure It Later"
This mindset is understandable. When you are learning, shipping feels difficult enough already. Security can feel like an advanced topic for a future version of yourself.
The problem is that insecure architecture hardens very quickly. Once real users arrive, technical debt compounds, insecure patterns spread through the codebase, and leaked secrets cannot be unexposed. The Moltbook breach did not happen because the founder planned to fix security later. It happened because the platform went viral before that moment came.
Security is not a decorative layer added at the end. It is part of the design. That does not mean you need perfection before you launch. It means security awareness needs to begin at the same time as everything else.
Your Security Stack, Kept Simple
You do not need to become a security engineer. You need a short checklist and the discipline to run it.
Start here — these take under an hour total:
- GitHub Secret Scanning — enabled by default on public repos, catches exposed keys automatically
- Gitleaks — run it locally before pushing; blocks commits containing secrets
- Supabase RLS — enable it on every table in your dashboard; follow the docs walkthrough
- Vercel Rate Limiting — enable it in your project settings before going public
- Snyk free tier — scans your dependencies for known vulnerabilities; integrates with VS Code
When your project gets more serious:
- Semgrep — static analysis that catches insecure code patterns in CI
- CodeQL — deeper analysis integrated into your GitHub pull request workflow
- Pre-commit hooks — stop dangerous commits before they leave your machine
Think of these tools as an automated second opinion. If AI is your fast-moving junior developer, security tooling is your automated reviewer. That combination is far safer than relying on intuition alone — especially when moving quickly.
One More Thing: Ask Your AI
One of the most underused techniques in vibe coding security is simply prompting for it. Before you ship any feature that touches user data, try this:
"Review this code for security issues. Check whether any credentials are exposed in client-side code, whether database tables have Row-Level Security enabled, whether API endpoints require authentication, and whether there is rate limiting on registration and data endpoints."
AI is quite capable of security review when asked explicitly. The problem is that it does not apply that review automatically. Make it a habit to ask. It takes thirty seconds and it will catch things.
A Fair Hearing for the Critics
The people arguing against vibe coding are not wrong. They are pointing at a real pattern: AI generates working code that skips assumptions a trained developer would never skip. Moltbook and Base44 are valid evidence of that.
But the conclusion — that people without traditional coding backgrounds should not build things — does not follow. What the evidence actually shows is that vibe coding without security awareness is dangerous. That is a different claim, and it has a different solution.
The Wiz Research team — the same team that found both breaches — put it clearly: the opportunity is not to slow down vibe coding but to elevate it. AI tools that generate Supabase backends can enable RLS by default. Deployment platforms can scan for exposed credentials automatically. The infrastructure for secure-by-default vibe coding exists. It just is not the default yet.
Until it is, the gap has to be filled by builders who know what to check — and who check it.
Before You Ship
[ ] No API keys or secrets in frontend code
[ ] Gitleaks run before pushing to the repository
[ ] Row-Level Security enabled on every database table with user data
[ ] Every API endpoint requires authentication, or is explicitly marked public
[ ] Rate limiting enabled on registration and data endpoints
[ ] NEXT_PUBLIC_ prefix checked — nothing sensitive uses it
[ ] Snyk or equivalent scanned your dependencies
[ ] Asked AI to review your code specifically for security issues
[ ] Opened the browser dev tools and checked what a stranger can see
AI is making software creation more accessible than ever. More people building means more innovation, more creativity, more diverse voices entering technology. That is a genuinely good thing.
But software engineering has always been more than generating working code. There is a layer underneath every application — trust, security, permissions, responsibility — that still belongs to the person who shipped it.
You do not need to learn everything before you build. You just need to know the layer exists, and make a habit of checking it.
The checklist is above. The tools are free. The rest is discipline. The future of software may be AI-assisted. But responsibility is still human.
Found this useful? Share it with someone who just shipped their first AI-built app. The person who needs it most is usually the one who doesn't know they need it yet.
Top comments (0)