Test IDOR by comparing what two accounts can reach, such as users in different tenants. AI pentesting agents do this automatically. In MindFort, add two test accounts to a target and turn on dual credential mode. Agents then test for IDOR, role bypass, and cross-tenant access. Each finding comes with a working exploit.
IDOR and cross-tenant bugs are authorization failures that only show up when you compare what two accounts can do. This guide explains what IDOR is, why AI agents are the practical way to test for it, and how to set that up with MindFort.
What are IDOR and BOLA vulnerabilities?
An insecure direct object reference (IDOR) happens when an app takes an ID from the request and loads the object without checking that the caller may access it. The OWASP testing guide (WSTG-ATHZ-04) describes it as changing a parameter to reach records that belong to other users. In APIs the same flaw is called broken object level authorization (BOLA). It is API1:2023 in the OWASP API Security Top 10 , rated widespread and easy to detect.
| Term | What crosses the line | Example |
|---|---|---|
| IDOR | One user reaches another user's object by changing an ID | GET /api/invoices/1043 returns someone else's invoice |
| BOLA | The API version of IDOR, per OWASP API1:2023 | PATCH /v2/orders/{id} accepts any order ID |
| Cross-tenant access | A user in tenant B reads or changes tenant A's data | An org member exports another org's users |
| Privilege escalation | A low-privilege user performs an admin action | A viewer calls DELETE /api/projects/7 |
Why is multi-tenant security so easy to get wrong?
Most SaaS apps keep every tenant in shared tables and rely on a tenant_id filter in application code. One query that forgets the filter leaks data across customers. OWASP ranks broken access control A01 in its Top 10:2025 and found it in 100% of the applications it tested. These bugs hide from functional tests because the app works perfectly for the owner of the data.
Why can't a normal scanner find IDOR?
A single-session DAST scanner can't tell that invoice 1043 belongs to someone else. It sees a 200 response and moves on. Finding IDOR means comparing what two accounts can reach on every request. Doing that by hand takes hours per release.
Can AI agents test for IDOR?
Yes. AI pentesting agents log in as two users, explore the app as each one, and compare what each can read or change. They use business logic testing to work out who owns an object and chain an exposed ID into a write, as in this JWT bypass and business logic chain. Platforms like MindFort run this end to end and prove each finding with a working exploit.
How do you set up AI pentesting for IDOR?
MindFort runs the two-account test for you. In dual credential mode , agents work through the app as both accounts and compare what each one can access. Setup takes four steps.
- Add two test accounts to the target. In Target Inventory, select the target and click Add Credential for each account. For example, add a user in tenant A and a user in tenant B. Add login instructions for each one and click Verify.
- Turn on dual credential mode. Start a new assessment and enable "Dual credential mode" in the Credentials section. The section appears once the target has at least two stored credentials.
- Pick a primary and a secondary account. Agents use both to test for IDOR and broken object level authorization. They also test role bypass, cross-user data access, and tenant isolation.
- Run it now or on a schedule. Recurring assessments keep the same primary and secondary accounts. Every release gets the same cross-tenant check.
Which test accounts should AI agents use for IDOR testing?
Run one assessment per access boundary you care about:
- Two regular users with separate data
- A low and a high privilege user
- Users from different tenants or workspaces
MindFort's docs recommend dedicated test accounts over personal or production admin accounts. Dedicated accounts also keep real customer data out of the test.
Can AI pentesting agents log in through SSO and MFA?
Agents sign in the way your users do, using any of the supported login methods :
- Password logins and SSO redirect flows
- Magic links and SMS login
- Authenticator (TOTP), SMS, or email MFA
- API keys sent as bearer tokens or headers
- API keys sent as query parameters or body fields
This matters for multi-tenant apps. Tenants often sit behind Okta or another SSO provider that a one-session scanner never gets past.
How do you tell AI agents which cross-account access is intended?
Shared workspaces, public links, and support access are often deliberate. Upload those rules as agent context along with architecture docs and accepted risks. Agents apply them on the next run. You can also add plain-language guardrails on the safety side, such as "Do not modify records outside the test workspace."
What happens after you fix an IDOR finding?
Retest the finding after you deploy the fix. Keep both credentials valid because the retest uses both saved accounts when the finding needs them. A retest costs 1 credit (see pricing). If one account's login fails, choose another credential from the finding details.
How do AI agents keep catching IDOR as your app changes?
Schedule a recurring dual credential assessment so every release gets the same cross-tenant check. MindFort also runs a security review on every pull request to catch new authorization gaps before they ship. When agents prove a cross-tenant bug, they open the fix as a pull request and retest it with both accounts after you merge. To provision test accounts and scope agents to a sandbox, see how to simulate attackers on your own sandboxes and apps.
FAQ
Do UUIDs prevent IDOR?
No. OWASP recommends random, unpredictable IDs as one layer of defense. The real fix for BOLA is an authorization check in every function that loads a record from client input. UUIDs still leak through shared links, logs, and exports. Other API responses expose them too. An attacker often does not need to guess them.
Is checking the user ID from the JWT enough to stop BOLA?
Not on its own. OWASP's API Security Top 10 says comparing the session's user ID with the ID parameter is not a sufficient fix for BOLA. The check must confirm that this user may perform this action on this specific object. It has to account for the user's tenant and role too.
Does Postgres row level security stop cross-tenant access?
It helps a lot. The database enforces the tenant filter even when application code forgets it. It does not cover code paths that connect as a privileged role. It also misses authorization rules that live outside the database. Keep testing through the API with two tenants either way.
How many test accounts do you need for IDOR testing?
Three is a practical minimum: two regular users in different tenants and one admin in one of those tenants. That covers user-to-user, cross-tenant, and user-to-admin access. In MindFort, each assessment compares one pair of accounts. Run one assessment per pair.
How much does AI pentesting for IDOR cost?
Dual credential mode is available on every plan. The Free plan includes 200 credits, enough for one Balanced assessment on one target. Starter is from $199 a month for 400 credits. A retest costs 1 credit.
About the author
Akul Gupta
Co-Founder & CTO · MindFort
AI researcher focusing on LLMs in cybersecurity. Red-teamed models for OpenAI and Anthropic as part of their safety programs. Published multiple conference papers. M.S. Computer Science, UIUC.