The short version. REST and GraphQL, assessed against the OWASP API Security Top 10 (2023). The engine probes object-level and function-level authorisation with separate identities, examines token handling, and attempts SSRF and injection — proving what it can and downgrading what it cannot.
What this engine does
Broken object-level authorisation is the top entry in the OWASP API Security Top 10 for a reason: it is invisible to signature scanning and trivial to exploit once found. Industry write-ups put BOLA at roughly 40% of observed API attacks (Total Shift Left, 2026). Detecting it needs exactly what a scanner lacks: a second identity and the patience to compare.
- BOLA / IDOR — object identifiers swapped between identities to see whether ownership is enforced server-side on every path.
- Broken function-level authorisation — privileged operations attempted with an unprivileged token.
- Broken object property-level authorisation — mass assignment and over-permissive responses that return fields the caller should not see.
- Authentication and token handling — JWT algorithm confusion, signature and expiry validation, session and refresh logic.
- SSRF through URL-accepting parameters, including the internal targets an attacker reaches for.
- Injection across REST parameters and GraphQL arguments, plus GraphQL-specific introspection and query-depth exposure.
- Security misconfiguration — CORS, verbose errors, missing rate limits, undocumented endpoints.
What it deliberately does not do
The same runner-level boundaries as the Web engine apply, plus two that matter specifically for APIs:
- No destructive calls. Endpoints that permanently change state are excluded, not merely deprioritised.
- No data extraction at volume. Proving a BOLA needs one object belonging to another identity, not a dump of the table.
- No brute force. Credential stuffing and password spraying are out of scope entirely.
- No unbounded load. Rate is governed per host; an API assessment must never read as a denial-of-service attempt.
- No scanning without authorisation. DCV on the domain or a signed attestation, else HTTP 403.
How we prove you are allowed to run it
Authorisation is a hard gate, not a checkbox in our terms. A scan starts only if the asset is verified by Domain Control Verification — you place a DNS TXT record or a file we specify — or you supply an explicit legal-authority attestation stating you own the target or are authorised to test it. A request carrying neither is refused with HTTP 403, at every tier, with no override. APIs usually live on a domain you already control, so DCV is the straightforward route; the attestation exists for cases where the API is hosted for you by someone else.
Where your data goes, and when it is deleted
Everything runs on EU infrastructure: edge functions in EU regions, scan compute in Frankfurt, object storage under EU jurisdiction, model inference through an EU endpoint. Nothing is used to train any model — ours or a third party's — and that is a contractual term in the DPA, which every plan gets.
- The report — kept two years, so you can hand it to an auditor next year.
- Raw uploaded material — third-party scanner files 30 days, application binaries 60 days, then deleted automatically.
- The anonymous homepage preview — content erased after 24 hours.
- The authorisation record — kept, because it is the evidence that the scan was permitted.
The full schedule is in our Privacy Policy, and the sub-processor list is on the Trust Center.
How a run actually works
The engine works best with two sets of credentials. With one identity it can find missing authentication and misconfiguration; with two it can prove cross-tenant access, which is the class of finding that actually costs money when it reaches production. Credentials ride the dispatch channel, are never written to our database, and are removed from the workspace when the run ends.
Analysis tracks run in parallel, then promising candidates go to an exploitation step that tries to demonstrate the flaw with a single, minimal request. If a proof cannot be produced, the finding ships as unconfirmed rather than as a Critical you cannot act on.
What you get at the end
Per finding: the exact request that demonstrated it, the identity it was made with, CVSS scoring, CWE and OWASP API Top 10 mapping, and remediation guidance aimed at the authorisation layer rather than at a WAF rule. The report distinguishes proven findings from unconfirmed ones on the summary page, so nobody has to read the whole thing to know what is real.
What this engine cannot find
Where an API engine stops, and what still needs a human or a different tool:
- Business-logic abuse that requires understanding your pricing, entitlement or workflow rules.
- Endpoints absent from any specification and not reachable by crawling — undocumented surface stays undocumented.
- Race conditions and timing-dependent flaws that need sustained concurrent load to reproduce.
- Flaws behind a role the supplied credentials do not hold.
- Anything requiring source-code review of the authorisation implementation itself.
We publish this list for the same reason we publish our own assessment report, limitations section included: a vendor that cannot tell you what its tool misses is asking you to take the rest on faith.
Frequently Asked Questions
What is BOLA and why does it matter more than injection?
Broken Object Level Authorization is when an endpoint returns or changes an object without checking that the caller owns it. It matters more because it needs no exotic payload — just a different identifier — and signature-based scanners cannot see it.
Do you support GraphQL as well as REST?
Yes. GraphQL is assessed for the same authorisation classes plus its own surface: introspection exposure, query depth and field-level access.
Do I have to give you credentials?
For a meaningful authorisation test, yes — ideally two accounts of different privilege. Without credentials the assessment covers the unauthenticated surface only, which is a much smaller slice of API risk.
Will the test create or delete records in our system?
Endpoints that permanently change state are excluded. Where a write is unavoidable to prove a finding, the engine stops at the minimum evidence needed and never attempts deletion.
How is this different from running a scanner against our OpenAPI spec?
A spec-driven scanner checks that documented endpoints respond as documented. This engine checks whether one customer can reach another customer's objects, which is a question only a second identity can answer.