What security holes do AI-built apps have?
The most common are missing authorization (one user reaching another's data), open database rules, secret keys in front-end code, checks done only in the browser, no rate limits, unsafe handling of user input and model output, and logic errors in payments. They share a cause: the tool writes code that satisfies the prompt and the demo, and nobody asked it what an attacker would try.
The holes, in order of how often they matter
| Hole | What an attacker does | Detail |
|---|---|---|
| Missing authorization (IDOR) | Changes an ID to read or edit someone else's record | IDOR |
| Open database rules | Queries tables directly with the public key | RLS mistakes |
| Secrets in the browser | Copies a payment, AI or admin key from the JavaScript | Exposed keys |
| Front-end-only checks | Calls the API the hidden button would have called | Client-side authorization |
| No rate limits | Guesses passwords, floods sign-ups, runs up your AI bill | Rate limiting |
| Injection | Puts code or query fragments into inputs | SQL injection, XSS |
| Payment logic | Changes the price or skips payment | Stripe |
| Unsafe uploads | Uploads a file that runs or overwrites others | Uploads |
| Prompt injection | Instructs your AI feature to leak data or misuse tools | Prompt injection |
| Made-up dependencies | Registers a package name the AI invented | AI-suggested packages |
Why AI tools produce these
They are optimised to make code that runs and matches the request. Authorization, limits and validation are constraints nobody states in a prompt, so they are left out or half-done. The tools also borrow patterns from public code, including insecure defaults. Broken access control is first on the OWASP Top 10 for web applications for all software, not only AI-written code; AI simply produces more code with less review.
How they are found
Most need a person with two accounts and an idea of what the app should allow. Scanners find the configuration items and miss the logic. See whether a scanner is enough.
Fix them in this order
- Close anything that exposes data without login: open database rules, public buckets, leaked service keys.
- Close cross-user and cross-customer access.
- Move every secret server-side and rotate any that leaked.
- Fix payment trust: server-side prices and verified webhooks.
- Add rate limits and AI usage caps.
- Treat AI input and output as untrusted.
- Clean up error messages, headers and dependencies.
The first three account for most of the serious incidents involving AI-built apps that have been made public. They are also the quickest to check with the pre-launch security checklist.
Getting it checked
TrazTech offers vibe-coding QA and security review, listed from $2,000 CAD. Get at least one other quote on the same scope; the questions to ask a testing firm help compare them.
Related questions
- Is my vibe coded app secure?
- What is IDOR?
- Security testing a vibe coded app
- OWASP Top 10 for LLM applications
Get a scope for your app
Tell us what you built, what it stores and who is about to use it.
Get matchedCommon questions
Are AI-built apps less secure than hand-written ones?
Not inherently. The same holes appear in hand-written code. The difference is that nobody reviewed the AI's code as it was written, so they reach production more often.
Which one should I check first?
Authorization between users. It is the most common and the most damaging.