You built a dashboard. Each user has a profile at /api/users/42/profile. User 42 logs in, sees their name, email, billing history. Everything works.
Now change that 42 to 43. If the server returns user 43's profile to user 42's session, you have an IDOR vulnerability. Insecure Direct Object Reference. One of the most common and most damaging access control flaws in web applications.
No automated scanner on the market tests for it.
What IDOR Actually Is
IDOR happens when your application uses a user-supplied identifier to fetch data without verifying whether the requesting user is authorized to access it. The identifier could be a user ID in the URL, an order number in a query parameter, a file name in an API call, or an invoice ID in a POST body.
The pattern is everywhere:
/api/users/42/profile/api/orders/8812/api/invoices/INV-2024-0091/api/documents/abc-def-123
If your server takes that identifier, queries the database, and returns the result without checking that the logged-in user owns that resource, any authenticated user can access any other user's data by changing one value.
This is not an edge case. OWASP ranks Broken Access Control as the number one web application security risk. IDOR is the most common form of it. Bug bounty platforms consistently report IDOR as their most frequently submitted vulnerability type.
The damage is straightforward. An attacker doesn't need admin access. They need one valid account and a browser. They change a number in the URL, read the response, and repeat. Entire databases of user data have been extracted this way.
Why No Scanner Tests for It
Testing for IDOR requires something no traditional scanner can do: log in as two different users at the same time.
Think about what the test requires. You log in as User A. You access /api/users/A/profile and get User A's data. Then you log in as User B. You access /api/users/A/profile using User B's session. If the server returns User A's data, that's an IDOR.
That's a two-account test. Two separate authenticated sessions, two real users, and the ability to cross-test resources between them.
Traditional scanners can barely handle one authentication flow. They don't create accounts. They don't have email addresses to receive verification codes. They don't have phone numbers to receive SMS OTPs. If your app requires email or phone verification at signup, the scanner can't create a single account, let alone two.
Even scanners that accept a pasted session token only operate with one session. They crawl your app as User A, fuzz parameters looking for SQL injection or XSS, and move on. They never ask the question that IDOR testing requires: "Can User B access User A's resources?"
That question demands two perspectives. One session to establish what belongs to User A. Another session to attempt accessing it as User B. No scanner runs that test automatically because none of them can create and manage multiple authenticated identities.
Some security teams test for IDOR manually. A pentester logs in with two browser profiles, maps the endpoints, and swaps session tokens between them. It works, but it's slow, expensive, and happens once or twice a year. Every feature you ship between those tests goes unchecked.
How Axeploit Tests What Others Can't
Axeploit's AI agents don't need your credentials. They create their own.
Each agent has a real email address and a real phone number. When your app requires email verification, the agent signs up, receives the OTP, reads it, and completes registration. When your app sends an SMS code, the agent receives it on its own mobile number and enters it. No manual token pasting. No expired sessions.
The agents don't stop at one account. They create multiple accounts on your application. User A and User B. Both fully verified. Both with live authenticated sessions running in parallel.
Then the IDOR testing begins. The agents access resources as User A, note every identifier in the responses, and attempt to access those same resources using User B's session. User IDs in URLs, order numbers in API calls, document references in response bodies. The LLM understands what these parameters represent because it navigates your app like a real person, reading responses, understanding context, spotting patterns.
If User B can read User A's profile, the agents flag it. If User B can download User A's invoices, that gets flagged too. Every endpoint, every object reference, tested from both perspectives.
No configuration. No two-account setup guide. No manually mapped endpoints. You give Axeploit a URL and the agents handle the rest: account creation, phone and email verification, authenticated crawling, and cross-account access testing.
IDOR has been the number one access control vulnerability for years. It stayed invisible to automated tools because the tools couldn't create accounts, let alone two of them.
That limitation no longer exists.
Test your app for IDOR: https://panel.axeploit.com/signup
