Vibe Coding | 2026-08-12 | 8 min read
The Security Bug AI-Built Apps Keep Missing
IDOR is the simple security bug where changing an ID in a URL can expose someone else’s data. AI-built apps are especially likely to miss it unless every data request checks who is allowed to see the record.
Direct answer: IDOR, short for insecure direct object reference, happens when an app lets a user access a record by changing an ID in a URL or request without checking whether that user is allowed to see it. AI-built apps often miss this because the interface may look finished while the authorization logic is incomplete. The fix is to check ownership and permissions on every server-side data request, not only hide buttons in the UI.
Written by: Esmail Hanif, AI Visibility Strategist & Founder, Martecks
Short answer
IDOR is one of the easiest security bugs to understand and one of the easiest for AI-built apps to miss.
It happens when a user can change an ID in a URL or request and see data that belongs to someone else.
The real fix is not a nicer UI. The app must check on the server that the logged-in user is allowed to read, edit, delete, or download that exact record.
Plain-English example
Imagine your app has this URL: /invoices/123.
If a logged-in customer changes it to /invoices/124 and sees someone else’s invoice, that is the problem.
The app may have a login screen. It may look professional. It may even hide the other customer’s invoice in the menu. None of that matters if the data request itself does not check ownership.
Why AI-built apps miss it
AI coding tools are good at building screens quickly. Security bugs often live behind the screen.
A generated app may create routes, buttons, dashboards, forms, and database calls before it has a clear permission model. That makes the app feel done while the risky part is unfinished.
This is why vibe coding needs a security review before launch. The question is not only "does it work?" The question is "does it only work for the right person?"
IDOR vs broken access control
IDOR is a specific kind of broken access control.
Broken access control is the broader category: the app allows someone to do or see something they should not. IDOR is the version where the exposed object is usually referenced by an ID, file name, account number, document ID, or database record key.
| Term | Simple meaning |
|---|---|
| Authentication | Who are you? |
| Authorization | What are you allowed to access? |
| Broken access control | The app allows the wrong access. |
| IDOR | Changing an object ID gives access to another user’s data. |
| BOLA | API version of the same object-level authorization problem. |
What to check before launch
Use this checklist on any AI-built app that stores private records.
| Check | Question to ask |
|---|---|
| Read access | Can user A view user B’s record by changing an ID? |
| Edit access | Can user A edit a record they do not own? |
| Delete access | Can user A delete another user’s item? |
| File access | Can a private file be opened by guessing or copying a link? |
| API access | Do API routes check the user, tenant, role, and object owner? |
| Admin access | Can a normal user call an admin action directly? |
| Team access | Does the app separate personal, team, and company-level records? |
The safe pattern
Every private data request should check three things.
First: is the user logged in? Second: what role or account does the user belong to? Third: does this exact record belong to that user, account, team, or role?
Do that on the server. Hiding a button in the browser is useful for UX, but it is not security.
| Layer | What it should do |
|---|---|
| UI | Hide actions the user should not see. |
| Server route | Verify the logged-in user and permissions. |
| Database query | Filter records by owner, team, tenant, or role. |
| Logs | Record blocked access attempts and suspicious patterns. |
| Tests | Prove one user cannot read or change another user’s data. |
A simple prompt for your AI coding tool
Use this before shipping an app with users, files, invoices, projects, messages, orders, leads, or private dashboards.
- Review every route, API call, database query, and file download for broken access control.
- For each private object, check whether the server verifies the logged-in user is allowed to access that object.
- Do not rely on hidden UI elements as security.
- Add tests that prove user A cannot read, edit, delete, or download user B’s data.
- List every risky route and the exact fix.
Where this fits in the launch checklist
IDOR is not the only security check, but it is one of the first checks to run because it is easy to test and painful to miss.
Before a public launch, also check authentication, password flows, secrets, admin routes, form spam, input validation, payment webhooks, database rules, and backups.
Sources
These sources support the security framing and terminology.
Sources: OWASP Top 10: Broken Access Control, OWASP API Security: Broken Object Level Authorization, OWASP Authorization Cheat Sheet, OWASP Top 10 for LLM Applications
FAQ
What is IDOR? IDOR means insecure direct object reference. It happens when an app exposes a record, file, or object because it does not check whether the user is allowed to access that exact object.
Is IDOR the same as broken access control? IDOR is a specific form of broken access control. Broken access control is the larger category.
Why do AI-built apps miss IDOR? AI coding tools can build screens faster than they build permission models. The app can look finished while server-side authorization is incomplete.
How do you prevent IDOR? Check authorization on every private object request, filter database queries by owner or role, and add tests that try to access another user’s records.
Is hiding a button enough? No. Hiding a button helps the interface, but the server still needs to block unauthorized requests.
Final answer
If your app has private records, IDOR should be one of the first launch checks.
The test is simple: can one user change a URL, ID, or API request and see someone else’s data? If yes, do not ship. Fix the authorization logic first.