Case study: turning a BOLA/IDOR finding into a deterministic CI invariant

[Pazificateur69]

A typical BOLA finding starts with a simple observation: tenant B can read an object owned by tenant A when it knows, guesses, or reuses the object's identifier. The fix is usually small. The harder part is preserving the authorization boundary through later routing, ORM, middleware, and policy refactors.

The pazent/exploitspec-demo repository is a minimal, runnable example of encoding that boundary as an observable contract instead of testing a particular implementation.

The mechanism

The synthetic API has two identities: owner belongs to tenant-a; attacker belongs to tenant-b. The invariant performs this sequence:

1. owner creates a private invoice with a unique ID and payment reference generated at runtime.
2. ExploitSpec verifies that creation succeeded, then captures $.id and $.payment_reference from the response.
3. attacker requests the exact captured invoice ID using a separate actor session.
4. The result must be 403 or 404, must not contain the captured payment reference, and must not expose the invoice's tenant, customer, amount, or payment fields.

The condensed core of the specification is:

actors:
  owner:
    headers:
      Authorization: "Bearer owner-demo-token"
  attacker:
    headers:
      Authorization: "Bearer attacker-demo-token"

steps:
  - name: Owner creates a private invoice
    actor: owner
    request:
      method: POST
      path: /api/invoices
      json:
        customer_email: alice@tenant-a.example
        amount_cents: 4200
    expect:
      status: 201
      json:
        exists: [$.id, $.payment_reference]
    capture:
      invoice_id:
        json_path: $.id
      payment_reference:
        json_path: $.payment_reference

  - name: Another tenant cannot read the captured invoice
    actor: attacker
    request:
      method: GET
      path: "/api/invoices/{{ invoice_id }}"
    expect:
      status: [403, 404]
      body:
        not_contains: ["{{ payment_reference }}"]
      json:
        not_exists:
          - $.tenant_id
          - $.customer_email
          - $.amount_cents
          - $.payment_reference

Creating the object inside the test matters. A hard-coded object ID can pass because fixture data disappeared or because it never belonged to the owner in that environment. Capturing an ID from a successful owner request proves that the object existed immediately before the cross-tenant read. Checking both the denial status and the absence of sensitive fields prevents an empty 200 or a partially redacted response from being mistaken for a preserved boundary.

403 and 404 are both accepted because applications make different legitimate choices about hiding object existence. The invariant is the security property—no cross-tenant read and no selected data leakage—not a preference for one policy's status code.

The CI contract

The demo workflow builds the loopback-only API, runs this invariant, verifies the generated JUnit report has zero failures, and uploads it as an artifact. Its permissions are limited to contents: read.

The Action is pinned to the reviewed commit behind v0.1.0, rather than a mutable tag:

- name: Run the ExploitSpec Action
  uses: pazent/exploitspec@4835c59fc8342ad7c72e65828cf82b445d3f8aee # v0.1.0
  with:
    specs: specs
    base-url: http://127.0.0.1:18080
    format: junit
    report: artifacts/exploitspec-junit.xml

The other third-party Actions are SHA-pinned too, and Dependabot proposes updates for review. Here is a successful end-to-end run for the current demo commit.

Try the complete example

Requirements: Git and Go 1.25 or newer.

git clone https://github.com/pazent/exploitspec-demo.git
cd exploitspec-demo
go test ./...
go run ./cmd/demo-api

In a second terminal:

go run github.com/pazent/exploitspec/cmd/exploitspec@v0.1.0 \
  run \
  --base-url http://127.0.0.1:18080 \
  --format text \
  specs

The reusable Action is also available on the GitHub Marketplace.

What this does—and does not—prove

A passing run proves that this request sequence, with these two identities and these assertions, preserved the tested boundary at that point in time. It does not prove that the application has no other BOLA paths, that list/update/delete/export endpoints are safe, or that no unasserted metadata or side channel exists.

ExploitSpec v1 executes ordered HTTP requests. It currently has no browser or JavaScript execution, automatic credential refresh, loops, retries, conditional steps, or cleanup/finally hooks. It also does not create or destroy test data automatically. For a real deployment, use an isolated test environment, synthetic data, dedicated least-privilege identities, narrow allowed_hosts, and an explicit cleanup strategy.

The demo intentionally ships a fixed, local-only API with inert tokens. It is an integration example, not a claim that it discovered a vulnerability in a real service.

Technical question: for a BOLA regression in your own stack, is the stable contract 403, an existence-hiding 404, or either status combined with explicit non-leakage assertions—and how do you keep its test-data lifecycle deterministic in CI?