Siemba brings continuous IDOR testing to production APIs

Siemba has announced automated testing for insecure direct object reference (IDOR) as part of its API Security Testing capability, which tests REST, GraphQL and SOAP APIs for the vulnerability classes most likely to expose customer data.

A 200-endpoint API collection can be tested for IDOR in under an hour. The same coverage has typically taken a human tester days or weeks, working endpoint by endpoint, and produced a written report days after that. Siemba compresses both the testing and the reporting into a single continuous run, against the API as it is actually deployed, with no source code required.

What is IDOR, and why does it matter?

IDOR is an authorization flaw. A vulnerable endpoint fails to check whether the identifier a caller supplied belongs to them, so changing a single number or identifier in a request can be enough to view or modify someone else’s data. OWASP classifies it as broken object level authorization (BOLA), and ranks it first in the OWASP API Security Top 10.

The flaw does not require a sophisticated exploit. It is conceptually simple but tedious to verify exhaustively across every endpoint and parameter, which makes it one of the easiest classes of vulnerability to miss at scale, and one of the most consistently cited causes of API breach disclosures.

“Most API vulnerabilities aren’t exotic,” said Sandhya Prashanth, Chief Security Officer, Siemba. “They are one user’s session reading another user’s data because nobody checked. That is IDOR, and it drives a huge share of real-world breaches. It needs almost no source-level reasoning to find, only the discipline to test every endpoint against it, systematically. That is exactly the kind of work automation should be doing continuously, so security teams can spend their attention on what automation cannot reason about: chained flows and privilege boundaries.”

How does Siemba test for IDOR?

Testing starts from the API definition a team already maintains, supplied as an OpenAPI or Swagger file, a Postman collection, or a collection URL. The customer supplies a set of identifiers, and authenticated sessions are handled by the platform. Siemba writes and runs the resulting test cases across every endpoint carrying an ID-like parameter.

Each result is judged by reading the actual API response, not by matching a signature or a status code. A 200 carrying an empty result or a generic error page is not scored as a pass. This is what separates a confirmed finding from the volume of noise that makes automated authorization testing hard to trust, and it is why every finding Siemba returns arrives already written up with reproduction steps rather than queued for a reporting phase.

Each protocol is tested to its own specification. REST endpoints are tested individually across path, query, header and body parameters. GraphQL schemas are resolved through introspection analysis, then tested for schema exposure, query depth and batching abuse, alias overloading, and field-level authorization. SOAP operations are parsed from WSDL and tested for XML external entity injection, signature wrapping, SOAPAction manipulation, and WS-Security misconfiguration.

What automation covers, and what it does not

Confirmed findings are mapped automatically to nine of the ten categories of the OWASP API Security Top 10. The tenth, broken function level authorization, along with chained attack paths and nuanced privilege-boundary testing, is covered by Siemba’s certified penetration testers working from the same platform. An expert-led engagement therefore starts from a known baseline instead of beginning reconnaissance from zero, which puts more of the engagement budget into the work only a human can do.

The practical difference is coverage and continuity. A tester under time pressure samples endpoints. Automation tests all of them, across every ID-like parameter in every position. And a point-in-time engagement certifies an API on the day it ran, leaving every endpoint shipped afterward untested until the next one. Continuous testing closes that window.

Built to run against production

Customers control test pace through four throttle presets, from a stealth mode suited to business hours through to a turbo mode for dedicated testing windows, with independent control over requests per second, concurrent test cases, and request timeout. Freeze windows of up to 30 days let teams pause testing automatically around production freezes, peak trading periods, or critical releases, with no manual ticket required.

Together these controls mean IDOR testing runs against production, where the data and the authorization logic are real, rather than against a staging environment that has drifted from it.