Change one ID in an API request and you might see another customer's invoice. Here's how Siemba finds IDOR flaws across every endpoint in your API.
Your team has shipped a new invoice endpoint. Authentication works fine. The API returns a successful response. Your functional tests pass successfully.
But if User A changes an invoice ID in the request, can (and should?) they read User B's invoice?
That's an Insecure Direct Object Reference (IDOR) vulnerability. Also known as Broken Object Level Authorization (BOLA), as in the OWASP API Security Top 10 classification. It can expose another user's invoices, orders, account details, or other sensitive records through an API that otherwise appears to work correctly.
Checking every endpoint, every identifier, and every parameter manually takes time. A tester under pressure may sample a handful of endpoints and miss the one that exposes customer data.
Siemba tests your full API collection across REST, GraphQL, and SOAP with mapping to the OWASP API Top 10, including IDOR/BOLA vulnerabilities. Upload an OpenAPI/Swagger file, Postman collection, or collection URL to test every endpoint.
Siemba’s AI-driven offsec platform detects injection, data exposure, and access-control gaps while certified testers validate complex flows, privilege boundaries, and business logic.
Consider a simple invoice API: GET /api/v1/invoices/8841
User A authenticates and requests invoice 8841. The API returns the invoice. Everything looks correct.
Now User A changes the identifier: GET /api/v1/invoices/8842
If invoice 8842 belongs to User B and the API returns its contents without checking ownership, the application has an authorization vulnerability.
The endpoint may authenticate the caller correctly. It may validate the request and return perfectly structured JSON. The failure is more specific. It doesn't enforce whether that user is allowed to access that particular object.
Three things make this problem challenging to find at scale.
The request looks legitimate. The attacker doesn't necessarily need a malicious payload, an invalid token, or an unusual request. A valid user session and a different object identifier may be enough.
The same check must happen across the API. Invoices are only one example. Orders, customer profiles, documents, and other resources may have their own endpoints and identifiers. Testing one endpoint doesn't prove that the rest enforce ownership correctly.
A successful HTTP response doesn't tell the whole story. An endpoint returning 200 OK might expose another user's private data. It might also return an empty result or a harmless response. So, a scanner that relies on status codes alone cannot reliably distinguish those outcomes.
IDOR testing therefore requires systematic coverage and response-level validation, which is not based on just sending requests and collecting status codes.
Manual testing is useful for investigating individual endpoints. A tester can authenticate as one user, change an identifier, and check whether another user's record becomes accessible.
The problem is repeating that process across a large API collection (hundreds or thousands!).
Every relevant endpoint and ID-like parameter adds another set of test cases. Identifiers must be selected, authenticated requests constructed, responses examined, and findings documented. Repeat this for hundreds of endpoints, and the work quickly becomes time-consuming.
A point-in-time penetration test also captures the state of an API when the engagement runs. New endpoints and changes introduced afterward still need to be tested.
Siemba automates the repetitive part, so security teams can expand coverage without depending entirely on manual endpoint-by-endpoint checks.
|
Area to Consider |
Manual IDOR Testing |
Basic Status-code Scanning |
Siemba’s Automated IDOR Testing |
|
Coverage |
Depends on tester time and scope |
Depends on scanner capabilities |
Tests relevant endpoints across the supplied API collection |
|
Test setup |
Manually construct requests |
Configure scanner rules |
Import an API definition and provide identifiers |
|
Authorization checks |
Tester compares access and responses |
May miss object-level authorization flaws |
Generates IDOR test cases across ID-like parameters |
|
Finding validation |
Manual response inspection |
May rely on signatures or status codes |
Analyzes actual API response content |
|
Developer handoff |
Depends on documentation |
Depends on reporting capabilities |
Confirmed findings include reproduction steps |
|
Repeatability |
Requires repeated manual effort |
Depends on configuration and coverage |
Automates repeatable checks across the collection |
|
Testing environment |
Depends on engagement scope |
Depends on scanner configuration |
Can test deployed APIs with configurable request throttling |
Siemba turns an existing API definition into executable authorization tests, then validates the results against the responses the application actually returns.
Provide an OpenAPI or Swagger specification, a Postman collection, or a collection URL.
You don't need to handcraft a new test script for every endpoint or provide access to application source code. Siemba uses the API definition as its starting point.
Provide the set of identifiers required for testing. Siemba uses these to construct test cases for endpoints that contain ID-like parameters.
The goal is to check whether the API enforces object-level authorization when requests reference different records.
The platform handles authenticated sessions and prepares the requests needed to exercise the relevant endpoints.
This lets testing focus on the authorization question: Does the authenticated user have permission to access the specific object requested?
You get three coverage options:
● Comprehensive security coverage: performs both IDOR and DAST analysis
● IDOR: only IDOR analysis
● DAST: only DAST analysis
Siemba generates and executes test cases across every endpoint in the supplied collection that carries an ID-like parameter.
For REST APIs, it tests identifiers in path, query, header, and body parameters. This matters because an identifier can appear in different parts of a request, and checking only URL paths can leave authorization gaps untested.
Siemba also supports API security testing for GraphQL and SOAP, with protocol-specific analysis rather than treating every API as a REST endpoint.
This is where response validation matters.
A successful HTTP status code alone doesn't prove that a user accessed another person's data. Likewise, an empty result or generic error page shouldn't automatically be treated as a successful IDOR test.
Siemba examines the actual API response to determine whether the result supports a confirmed finding. This helps distinguish genuine authorization failures from misleading responses and reduces noise for the team investigating them.
Confirmed findings arrive with reproduction steps, including the request details developers need to investigate the problem.
Siemba's API Security Testing supports REST, GraphQL, and SOAP APIs and maps confirmed findings to nine of the ten categories in the OWASP API Security Top 10. Broken function-level authorization, the remaining category in this coverage, is addressed through expert-led penetration testing.
Instead of waiting for a separate reporting stage, teams can move directly from detection to reproduction, remediation, and retesting.
The result is a more continuous testing workflow: automated coverage, response-based validation, and actionable findings in a single run. According to Siemba's September 2026 announcement, a 200-endpoint API collection can be tested for IDOR in under an hour.
Manual coverage would have typically taken testers days or weeks. However, the actual runtime depends on the API collection and testing configuration.
The important difference isn't simply speed. It's the ability to apply the same systematic checks across a large API surface, rather than relying on a limited sample of endpoints.
Yes. Siemba's API security testing is designed to test deployed APIs, where the actual authorization logic and data are present.
Production testing, however, requires control over the rate and timing of requests. An aggressive test run can compete with normal application traffic, especially during peak usage or critical business periods.
Siemba provides four throttle presets, ranging from a stealth mode suited to business hours to a turbo mode for dedicated testing windows. Teams can also control requests per second, concurrent test cases, and request timeouts independently.
Freeze windows of up to 30 days let teams automatically pause testing around production freezes, peak trading periods, or critical releases.
These controls help teams balance testing coverage with operational requirements. Production testing should still be appropriately authorized, scoped, and configured for the environment being tested.
Read more: Automated IDOR Testing: What Tools Catch and Humans Confirm.
No. It makes penetration testing more efficient by handling systematic checks that are repetitive and well suited to automation.
IDOR testing checks: Can one user access another user's object by changing an identifier without the required authorization?
But authorization failures can extend beyond a single object reference. Some vulnerabilities depend on how multiple actions are chained together, how permissions change between workflow stages, or where privilege boundaries should exist.
For example, an API might enforce ownership checks on an invoice endpoint but fail when a user reaches the same record through a multi-step approval workflow. Other flaws may involve access to privileged functions rather than individual objects.
These cases can require contextual reasoning and expert-led investigation.
Siemba's automated testing establishes a baseline across the API collection. Its certified penetration testers can then focus on broken function-level authorization, chained attack paths, and nuanced privilege-boundary testing.
Automation gives experts broader coverage to start from. Experts investigate the cases that require human judgment.
It's particularly useful if:
Automated IDOR testing is not a substitute for a complete security program. It addresses a specific, high-impact authorization risk and complements broader API testing, business-logic assessment, and expert security reviews.
Explore Siemba API Security Testing to see how it works.
How many endpoints have you actually tested for IDOR? To see where your security program stands →Book a free assessment today.
Siemba's API Security Testing supports REST, GraphQL, and SOAP APIs. Testing is adapted to each protocol's specification and capabilities.
HTTP 200 indicates that a request was handled successfully at the HTTP level. It doesn't establish whether the caller was authorized to access the requested object. The response could contain another user's sensitive data, an empty result, or a generic response. Confirming IDOR requires examining the actual response and the authorization context.
Siemba automates IDOR test-case generation and execution across every endpoint in the supplied collection that carries an ID-like parameter. Coverage depends on the supplied API definition, available identifiers, and the endpoints and parameters exposed for testing.
No. Automation is suited to systematic, repeatable checks across large API collections. Expert-led penetration testing remains important for chained attack paths, complex privilege boundaries, and broken function-level authorization that require deeper contextual analysis.
Identify, test, and remediate security weaknesses across modern apps, including AI agents, LLMs, MCPs, and supporting infrastructure → Book a Demo.