AuthProbe: Specification-Driven, Multi-Identity Detection of Broken Object-Level Authorization in Recruitment API

Source: arXiv:2607.20574 · Published 2026-07-22 · By Jay Barach

TL;DR

This paper addresses Broken Object-Level Authorization (BOLA), also known as Insecure Direct Object Reference (IDOR), a pervasive API security flaw responsible for large data exposures in recruitment platforms. The defining challenge of BOLA is that malicious requests are indistinguishable from legitimate ones at the HTTP layer, rendering conventional signature-based firewalls and single-identity scanners ineffective. AuthProbe, the proposed solution, is a black-box, specification-driven scanner that exploits multiple controlled identities to detect BOLA by discovering legitimate object ownership and attempting cross-identity access to confirm leaks via response comparison. The tool is open-source, integrates with OpenAPI specifications, and produces machine-readable output suitable for CI pipelines.

AuthProbe was evaluated on a synthetic recruitment API testbed modeling the McHire failure incident of 2025. The tool detected 100% of planted cross-identity read flaws without false positives on a hardened version, confirming the soundness of its detection predicate. Additionally, AuthProbe scales linearly in runtime with the number of tested objects, making it practical for continuous integration use. This work provides a unique point in the security tooling space by combining black-box testing, multi-identity context, specification-driven exploration, and CI integration to catch a top-ranked API vulnerability.

Key findings

• AuthProbe detects every planted cross-identity read (BOLA/IDOR) in a synthetic recruitment API reproducing the McHire incident.
• No false positives were reported on a hardened target with enforced ownership checks and non-guessable identifiers.
• Running time scales linearly with the number of objects under test; 16ms at 1 object to 114ms at 50 objects per identity.
• Seven high-severity and one medium-severity findings reported on vulnerable target versus zero on hardened target (Table III, Fig 2).
• The detection method relies on response differencing against ground-truth fetches by true owners, requiring multi-identity testing.
• Identifier enumeration probing exposes predictable numeric identifier schemes and cross-identity access, linking to ASVS API1:2023.
• Severity-thresholded exit code enables effective CI pipeline gating for regression prevention.
• AuthProbe supports both local and remote targets with authorization guardrails to prevent misuse.

Threat model

The adversary is assumed to be a principal with a valid, authenticated session (identity) in the API, but who is unauthorized to read certain objects owned by other principals. The attacker attempts to access these unauthorized objects via well-formed, legitimate API calls. The adversary cannot escalate beyond their authorized identities or forge requests that deviate from protocol syntax. AuthProbe operates from outside the server as a black-box tester with control over two or more known identities used to discover ownership and detect cross-identity leaks.

Methodology — deep read

The threat model considers an HTTP API managing objects owned by principals, each identified by unique identifiers. The adversary is a principal with a valid session attempting to access objects owned by others (BOLA scenario). Detection requires at least two tester-controlled identities.

AuthProbe requires an OpenAPI specification to identify candidate resources with collection and item paths (e.g., /applications and /applications/{app_id}). For each resource, it performs ownership discovery by listing objects visible to each identity via the collection endpoint, thus deriving ground-truth ownership mappings without insider knowledge.

Next, for each identity pair (attacker, victim), AuthProbe attempts to fetch victim objects while authenticated as the attacker. The detection predicate asserts a leak if the response status is successful, the body represents an object whose identifier matches the requested one, and the object is not owned by the attacker. This confirmation step drastically reduces false positives by excluding generic or transformed responses.

Additional probes include identifier enumeration (checking if numeric IDs can be sequentially traversed to reach unauthorized objects), missing authentication checks (detecting if data is exposed without credentials), and existence oracle checks (whether unauthorized vs nonexistent objects yield distinguishable response status codes).

Severity levels (critical, high, medium, low) map to OWASP API security categories and inform a CI gate exit code that fails builds on high-severity or above.

The implementation is in Python, uses standard HTTP clients and YAML parsers, and outputs findings in console, JSON, Markdown, and JUnit formats for easy pipeline integration. Two shipping target services mimic vulnerable and hardened recruitment APIs for end-to-end validation.

All experiments were run locally, resetting in-memory stores before each run for reproducibility. Two identities (“alice” and “bob”) each owned a small number of objects. Findings were analyzed in severity buckets to assess detection correctness and false positives. Scaling was measured by increasing the number of objects per identity from 1 to 50. Runtime scaling matched the O(|I|^2 * m) theoretical complexity but approximates linear with a small fixed number of identities.

This methodology emphasizes a fully black-box, multi-identity, specification-driven approach suitable for automated integration into modern CI pipelines, prioritizing precision and low false positives over coverage completeness (e.g., objects undiscoverable via collection endpoints or transformed responses might evade detection).

Technical innovations

• Multi-identity black-box scanning based on ownership discovery via collection endpoints, enabling detection of cross-identity BOLA.
• Response differencing confirmation predicate that requires returned object’s identifier to match requested identifier reduces false positives.
• Specification-driven resource detection automatically pairs collection and item endpoints from an OpenAPI document.
• Four complementary probes (BOLA, identifier enumeration, missing authentication, existence oracle) mapped to OWASP API security taxonomy.
• Severity-thresholded exit code and machine-readable reports enable seamless CI/CD build pipeline gating.

Datasets

• Synthetic recruitment API testbed — small scale with fabricated data — shipped with AuthProbe implementation

Baselines vs proposed

• On vulnerable target: 7 high-severity + 1 medium-severity findings; on hardened target: 0 findings (Table III)
• Scan time scales from 16ms at 1 object per identity to 114ms at 50 objects per identity, linear trend (Fig 3)
• Compared against signature-based WAFs and single-identity scanners, which cannot detect BOLA due to lack of cross-identity context (Section VII.F)

Limitations

• Testbed is synthetic, so real-world generalization requires further field validation.
• Detection relies on existence of a collection endpoint to discover object ownership, limiting applicability on APIs with unlistable resources.
• The leak confirmation requires the victim’s object identifier to be present verbatim in the response, potentially missing transformed or opaque responses.
• Number of identities used in detection is small and fixed; scaling to more identities may increase cost quadratically.
• Does not attempt to detect authorization flaws on write or mutation operations, focusing on read-only item fetch.
• No evaluation under active adversarial manipulation or adaptive attacker behavior.

Open questions / follow-ons

• How well does AuthProbe perform across diverse real-world recruitment APIs with varying authorization schemes and non-RESTful conventions?
• Can the approach be extended to detect broken authorization on write/update/delete operations or complex multi-step authorization flows?
• What strategies can improve coverage and detection completeness for APIs that lack collection endpoints or return transformed object responses?
• How resilient is AuthProbe under adversarial conditions, such as rate limiting, anomaly detection, or API mutation?

Why it matters for bot defense

AuthProbe highlights the critical role of multi-identity contextual testing and specification-driven approaches in detecting authorization flaws that single-identity scans or signature-based defenses cannot catch. For bot-defense and CAPTCHA practitioners, it underscores the importance of modeling object ownership and multi-session behaviors to distinguish legitimate from unauthorized access attempts, especially in API-driven ecosystems.

Implementing similar multi-identity detection could complement rate-limiting and anomaly heuristics in bot defense, especially where attacks exploit valid sessions to access unauthorized data. AuthProbe's integration into CI pipelines also illustrates a practical workflow to prevent regressions of these high-impact vulnerabilities early in development, an approach transferable to security testing of other access control mechanisms relevant to automated abuse mitigation.

Cite

@article{arxiv2607_20574,
  title={ AuthProbe: Specification-Driven, Multi-Identity Detection of Broken Object-Level Authorization in Recruitment API },
  author={ Jay Barach },
  journal={arXiv preprint arXiv:2607.20574},
  year={ 2026 },
  url={https://arxiv.org/abs/2607.20574}
}

Read the full paper

• arXiv:2607.20574 (abstract)
• arXiv:2607.20574 (PDF)