An OpenAPI-driven, multi-identity BOLA/IDOR scanner for recruitment (and other) APIs. AuthProbe logs in as two or more identities you control, walks and enumerates object IDs, and diffs the responses to detect when one identity can read another's records — the Broken Object Level Authorization (BOLA/IDOR) flaw class behind incidents like McHire. It's driven by the target's OpenAPI spec and returns a non-zero exit code so it can gate your CI build.

⚠️ Authorized use only. Run AuthProbe against APIs you own or are explicitly permitted to test. It refuses non-local targets unless you pass --i-have-authorization. See SECURITY.md.

Broken Object Level Authorization has been the #1 OWASP API risk since 2019, and it is precisely the class of flaw that WAFs and single-identity scanners cannot catch — a BOLA request is a syntactically valid request. Finding it requires contextual, multi-identity, object-level testing: log in as A, try to read B's object, and see if it leaks. AuthProbe automates exactly that, from an OpenAPI spec, in CI.

git clone https://github.com/jbarach2012/AuthProbe
cd AuthProbe
pip install -e ".[test]"

python -m authprobe.demo     # spins up a vulnerable + a secure demo ATS and scans both
pytest -q                    # 11 tests

Demo output:

=== Scanning VULNERABLE target ===
  [HIGH] Broken Object Level Authorization (BOLA)   alice retrieved object '2' owned by 'bob'
  [HIGH] Broken Object Level Authorization (BOLA)   bob retrieved object '1' owned by 'alice'
  [HIGH] IDOR via sequential-ID enumeration         alice reached non-owned objects [2] ...
  [MED ] Enumerable (sequential/numeric) identifiers
  summary: 4 finding(s) [high=3, medium=1]

=== Scanning SECURE target ===
  AuthProbe: no authorization findings.

# 1. write a config (see examples/config.example.yaml)
# 2. run:
authprobe scan --config myconfig.yaml --format console json junit --out out/
echo "exit code: $?"   # non-zero if findings at/above fail_on

Minimal config:

target:
  base_url: "http://127.0.0.1:8000"
  spec: "auto"                       # fetch {base_url}/openapi.json
identities:
  - name: alice
    headers: { Authorization: "Bearer alice-token" }
  - name: bob
    headers: { Authorization: "Bearer bob-token" }
settings:
  fail_on: high

Provide two identities you control. AuthProbe auto-detects (GET /collection, GET /collection/{id}) resource pairs from the spec (you can also declare them explicitly), discovers which objects each identity owns via the list endpoint, then runs its probes.

How it decides a leak happened: it fetches each object as its owner to capture a ground-truth view, then, as a different identity, refetches and confirms the response really returns that object (matching id_field). This response-diffing is what separates a true BOLA from a normal 404.

AuthProbe emits JUnit XML and exits non-zero when findings reach fail_on:

- run: authprobe scan --config authprobe.yaml --format junit --out out/ --fail-on high

A regression that reintroduces an IDOR fails the build — the McHire class of bug, caught before production.

• HR-tech / API teams get the one test that catches their most likely and most damaging flaw, spec-driven and CI-gated.
• Security reviewers get repeatable, evidence-producing authorization tests instead of manual Burp sessions.
• The community gets an open, Apache-2.0 BOLA/IDOR scanner purpose-built for the multi-tenant, high-PII reality of recruitment APIs. It is the offensive counterpart to a secure-by-design candidate-data layer: one shows how to build it safely, this proves whether you did.

Overview · How it works · CI integration · Security policy · Roadmap

Apache 2.0. AuthProbe is a defensive testing tool; use it responsibly and only where authorized.