The 5 Vulnerabilities Your AI-Built App Probably Has (and How to Find Each One)
Your AI-built app works, looks great, and is even attracting customers — but AI didn't tell you it left doors open. Inspired by Mano Devin's video, this guide lists the 5 most common flaws in apps created with Vibe Coding and shows free tools to find and close each gap.
Launching a SaaS with Vibe Coding is almost a rite of passage for indie devs these days. Tools like Cursor, Claude Code, Lovable, and Bolt deliver a working app in hours. But what AI doesn't tell you is that it might be leaving several doors open along the way.
The Mano Devin channel, a reference in security for Brazilian devs, published an unmissable video analyzing the five most common blunders in AI-built apps — and worse: they're found in serious, enterprise-level apps, not just weekend projects.
The problem isn't AI. The problem is that it optimizes for "working," not for "withstanding attacks."
Below, the 5 vulnerabilities, explained with real examples, and how you can find each one yourself — for free.
1. RLS disabled — the vault without a door
If you use Supabase or Firebase, your database communicates directly with the browser. There isn't a backend server protecting data transactions. The protection in this model is called RLS (Row Level Security): a lock that ensures each user only sees their own data.
The problem? RLS comes disabled by default. It's like buying an imposing vault, putting it in your office, but leaving the door unlocked.
Real data: 83% of Supabase leaks are related to misconfigured or disabled RLS, according to a 2025 study. A CVE last year exposed data from over 170 applications at once.
And what's worse: Yuri Dev showed a case where someone simply asked for the application's database — and the database delivered. Reseller names, WhatsApp, stores. No password, no intrusion. Just asked.
How to find: Access the Supabase panel, go to SQL Editor, and run SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';. Tables with rowsecurity = false are unlocked.
How to solve: Activate RLS on each table and create access policies. One line of SQL resolves it.
2. Admin permission in the frontend — the localStorage that decides who's in charge
This is a classic and alarmingly common one. The app defines whether the user is an administrator or not directly in the frontend, usually in the browser's localStorage.
Yuri Dev demonstrated: he opened Inspect Element, changed admin: false to admin: true in localStorage, refreshed, and gained access to the administrative panel. The most famous case was that of influencer Riter (22 million followers), where a single word change in localStorage unlocked entire courses that hadn't even been launched yet.
Golden rule: business logic lives in the backend, not the frontend. The frontend only renders. If you let the browser decide who is admin, the browser becomes the hacker's best friend.
How to find: Open your browser's DevTools (F12), go to Application > Local Storage, and look for fields like admin, role, isAdmin, userType. If they are in the frontend and the backend blindly trusts them, you have a vulnerability.
How to solve: All permission verification must be validated on the server. The frontend can display or hide buttons, but the backend is who decides if the request is authorized.
3. IDOR — the pharmacy counter that gives everyone's data away
IDOR (Insecure Direct Object Reference) is one of the easiest vulnerabilities to exploit and most overlooked by Vibe Coding. The logic is simple:
Imagine a pharmacy counter. You walk up and say "order 105". The attendant hands it over. You say "order 106". They hand that over too. 107, 108... In 5 minutes you've taken all the orders on the street.
That's exactly what happens when a route like /api/user/3 returns user 3's data without checking if you are user 3. The attacker changes the number in the URL and gets the neighbor's data: phone, balance, email.
How AI contributes: When you ask for "create a user CRUD" or "order search route by ID," AI generates exactly that — an endpoint that searches by ID, without verifying if the ID belongs to the logged-in person. If you don't ask for this verification, it won't be included.
This is #1 on the OWASP API vulnerabilities list.
How to find: Use OWASP ZAP (free tool). Give it your app's address, and it will start hitting all routes and testing ID variations.
How to solve: Always check if the requested resource belongs to the authenticated user. Never trust the ID sent by the client without validating ownership.
4. Hard-coded API keys — the secret that became public
This is the blunder that hands over your application's password to anyone who opens Inspect Element.
Every integration (payment gateway, email, cloud storage) provides an API key. This key must reside on the server, in an environment variable. But AI, if you're not careful, simply hard-codes it into the code.
And what's worse: when you build the frontend, every variable becomes public JavaScript. Anyone can read it by opening DevTools.
In 2024 alone, 24 million secrets leaked this way, according to a security survey. Bots scan GitHub in real-time for exposed keys.
Yuri Dev showed the case of a scammer who found a payment gateway key inside a public file on GitHub. In his words: "the scammer never heard of .gitignore."
How to find: Use Gitleaks (gitleaks detect --source .) to scan your repository for leaked keys, passwords, and tokens in the Git history. Even if you deleted them later, the history retains them.
How to solve: API keys never go in the frontend. Use environment variables (process.env.API_KEY) on the server, and proxy endpoints in the backend for any external service.
5. XSS — the feature that was a flaw
This is the most treacherous because it doesn't look like a flaw — it looks like a feature.
Riter's case: the course had a "custom HTML" field in the panel, which allowed writing code that ran on all pages. And for profile uploads, it accepted any file. They sent an image with a hidden script inside and stole the admin's session.
This is called XSS (Cross-Site Scripting). The user types code instead of text, and the site executes that code, believing it to be legitimate content.
45% of AI-generated code has this type of flaw, according to Veracode. Almost half.
The rule is simple: in a secure system, everything the user types is a lie until proven otherwise. Treat input as hostile.
How to find: Use OWASP ZAP (which has an automatic XSS scanner) or TruffleHog (open source fork of the Srap project). Both are free.
How to solve: Validate, sanitize, and limit all user input. Never trust that content is safe just because it came from a text field.
How ecoa.dev helps you close these gaps
ecoa.dev was made precisely to bridge this gap between "working app" and "secure app".
ecoa.dev's Scan Service performs a complete scan in minutes:
- Discovers exposed sensitive endpoints (
.env,.git, administrative panels) - Checks security headers (HSTS, CSP, secure cookies)
- Tests forced HTTPS redirection, SSL/TLS
- Detects vulnerabilities like SSRF and injection
Additionally, the LGPD Analyzer checks if your app complies with Brazilian law — privacy policy, cookies, data subject channel. The type of checklist no Vibe Coding tool generates on its own.
And when the scan finds a flaw, ecoa generates a fix prompt ready for you to paste back into your favorite AI tool. You don't need to understand deep security: just copy, paste into Cursor or Claude, and the AI adjusts the code.
Test your app at ecoa.dev before someone else tests it for you.