Imagine a bank that wrote its vault combination on the lobby wall. Not hidden behind the counter. Not whispered to authorized employees. Written in large print, right next to the potted plant, where every customer and every passerby could read it. That is essentially what Moltbook did with 1.5 million authentication tokens.
Moltbook was a social networking app built entirely with AI coding tools. The founder used Lovable to generate the application without writing a single line of code by hand. The app worked. Users signed up, created profiles, and shared content. Everything looked polished and professional on the surface.
Underneath, the vault combination was on the wall.
What Actually Happened
Security researchers discovered that Moltbook's public API endpoints were returning authentication tokens in plaintext responses. These tokens are the credentials that prove a user's identity to the system. Every logged-in user had one, and every one of those tokens was accessible to anyone who sent the right API request.
No hacking was required. No brute-force attack. No social engineering. The API simply handed over tokens when asked. A single GET request to the right endpoint returned user data that included active authentication tokens, and the endpoint required no authentication itself. The vault combination was not just on the lobby wall. The bank had removed the vault door entirely.
The total exposure included 1.5 million authentication tokens and approximately 35,000 user email addresses. With those tokens, an attacker could impersonate any user on the platform, access their private data, send messages on their behalf, and modify their accounts. This was not a theoretical risk. It was a fully exploitable vulnerability sitting in production, accessible to anyone with a web browser and basic knowledge of how APIs work.
The Technical Breakdown
Three distinct failures combined to create this breach. Each one alone would have been a serious vulnerability. Together, they turned Moltbook into an open book.
Missing endpoint authentication. The API endpoints that returned user data did not verify whether the requester was authorized to see that data. In a properly built application, every API endpoint checks the incoming request for a valid session or token before returning anything. Moltbook's endpoints skipped this step entirely. They accepted any request from any source and returned full user records in response.
Token exposure in API responses. Even if the endpoints had been properly authenticated, returning raw authentication tokens in API responses is a fundamental security mistake. Tokens should never appear in response bodies. They belong in HTTP-only cookies or secure headers, not in JSON payloads that any client-side JavaScript can read. Moltbook stored tokens in a way that made them part of the standard user data response, so every API call that returned user information also returned the keys to that user's account.
No rate limiting. With no rate limiting on the API, an attacker could enumerate through every user in the database by sending rapid sequential requests. There was no throttling, no IP-based limits, no request caps. An automated script could harvest all 1.5 million tokens in hours. The bank did not just leave the vault combination on the wall. It left the front door open 24 hours a day with no security guard.
The Moltbook leak was not caused by one mistake. It was caused by the complete absence of a security layer. No endpoint auth, no token protection, no rate limiting. When AI generates your backend code, you must verify that all three of these exist before deploying. Missing even one creates a path to user data exposure.
Why AI Tools Miss These Problems
According to recent industry data, 92% of developers now use AI tools daily in their workflow. That adoption rate is staggering. But research also shows that AI-generated code ships 1.7x more major security issues than human-written code. The gap between adoption and safety is where incidents like Moltbook happen.
AI coding tools are optimized for functionality. When you tell Lovable, Cursor, or any other AI tool to "build a social app with user profiles," it generates code that creates profiles, stores data, and serves API responses. The code works. Features function. The app does what you asked it to do.
What the AI does not do, unless explicitly instructed, is think about what the app should prevent. Security is primarily about prevention, and AI tools are primarily about creation. They build the vault. They do not automatically add the lock. They wire the alarm system. They do not automatically turn it on.
This is not a flaw in the AI itself. It is a gap in how most people use these tools. The prompts focus on features, not safeguards. "Add user authentication" gets you a login flow. It does not necessarily get you token rotation, secure storage, rate limiting, or endpoint authorization. Those are separate concerns that require separate instructions, or better yet, a security review after the AI finishes building.
What the Developer Could Have Done Differently
The Moltbook breach was entirely preventable. Here are the specific steps that would have stopped it.
Run a security audit before launch. Free tools like OWASP ZAP can scan your application for common vulnerabilities in minutes. A basic scan would have immediately flagged the unauthenticated endpoints returning sensitive data. This single step would have caught the entire breach.
Add middleware-level authentication. Instead of relying on each individual endpoint to check authorization, implement authentication at the middleware layer. In Next.js, this means a middleware function that runs before every API route and rejects unauthenticated requests. In Express, it is a middleware function applied to your router. This approach ensures that no endpoint can accidentally skip the auth check because the check happens before the endpoint code runs.
Never return tokens in API responses. Authentication tokens should be set as HTTP-only cookies by the server and never included in JSON response bodies. HTTP-only cookies cannot be read by client-side JavaScript, which eliminates an entire category of token theft. If you are using a tool like Supabase Auth or Clerk, they handle this correctly by default. If the AI generated custom auth logic, review exactly how tokens are stored and transmitted.
Implement rate limiting from day one. Rate limiting prevents attackers from making thousands of requests per second to enumerate your data. Libraries like express-rate-limit or Cloudflare's built-in rate limiting can be configured in minutes. Set reasonable limits (100 requests per minute per IP is a common starting point) and adjust based on your actual usage patterns.
Rotate tokens regularly. Even if a token is exposed, its damage is limited if it expires quickly. Set short expiration times for access tokens (15 minutes is standard) and use refresh tokens for longer sessions. This means that even if an attacker captures a token, it stops working within minutes.
The Vault Combination Test
Here is a simple mental model for checking your own application. I call it the vault combination test, based on the analogy that has been running through this entire case study.
Walk through your application as if you were a stranger. Open your browser's developer tools. Look at the network tab while you use your app. For every API response you see, ask yourself three questions.
Does this response contain information that should be private? If it includes tokens, passwords, email addresses, or internal IDs, flag it. Does this endpoint verify who is making the request? Try hitting the same URL in an incognito window without logging in. If it returns data, you have a Moltbook-level problem. Could someone automate requests to this endpoint and collect data at scale? If there is no rate limiting, the answer is yes.
If any response fails all three questions, you have a vault combination on the lobby wall. Fix it before you launch. Fix it before you tell anyone the URL. Fix it now.
Many vibe coders assume that if their app uses a login system, the API is automatically protected. This is wrong. Authentication (proving who you are) and authorization (checking what you can access) are separate systems. Moltbook had authentication for its frontend login flow but zero authorization on its API endpoints. Users could log in, but the API did not care whether a request came from a logged-in user or a random script.
Learn the security fundamentals every vibe coder needs before shipping to production.
Read the security guideLessons for Every Vibe Coder
The Moltbook case study is not a warning against using AI tools. It is a warning against using them without verification. The tools are powerful. They generate functional code at remarkable speed. But functional is not the same as secure, and speed without review is just faster exposure.
Every application you build with AI tools needs a security pass before it goes live. Not a casual glance. A structured check. Run a scanner. Review your API responses. Test your endpoints without authentication. Check your rate limits. Verify your token handling. These steps take an hour. Skipping them can expose millions of user records.
The bank that wrote its vault combination on the lobby wall did not get robbed because the vault was weak. The vault was fine. The problem was that nobody checked whether the combination was visible. In vibe coding, the AI builds the vault. Your job is to make sure the combination stays hidden.
The 1.5 million tokens exposed in the Moltbook breach represent 1.5 million users whose accounts could be taken over. Real people. Real data. Real consequences. The next time you ship an AI-built application, run the vault combination test. It takes ten minutes. The alternative takes years to recover from.
Start with the right foundation so you never end up as a case study.
Start here