API Exploit Prover

API Exploit Prover

When To Use

Use this after discovery identifies candidate API weaknesses.

Inputs

• candidate_findings
• target_base_url
• auth_and_role_context
• test_data_or_seed_objects
• constraints (noise limits, forbidden write actions)

Confidence Model

• C0: hypothesis only
• C1: suspicious signal
• C2: reproducible behavior anomaly
• C3: exploit primitive proven
• C4: business impact proven

Execution Workflow

Phase 1: Reproduction Baseline

1. Replay original request as control.
2. Capture stable baseline across repeated requests.
3. Validate request preconditions (auth, ownership, object existence).

Phase 2: Alternative Technique Check

1. Re-test with a different method than original lead.
2. Vary payload shape and transport encoding.
3. Confirm behavior survives minor variance.

Phase 3: Impact Escalation

1. Attempt controlled state change or unauthorized data access.
2. Test cross-tenant and cross-role boundaries where legal.
3. Validate whether impact persists after session/token refresh.

Phase 4: Confounder Elimination

1. Rule out caching and stale object state.
2. Rule out test-environment race artifacts.
3. Rule out expected business behavior incorrectly interpreted as vulnerability.

Phase 5: Classification

1. confirmed only when exploit and impact are replayable.
2. disputed when mitigation or expected behavior is proven.
3. inconclusive when blockers prevent decision.

Technique Rules by Vulnerability Type

Evidence Requirements

• Exact request and response pairs.
• Reproduction count and variance notes.
• Auth role used in each attempt.
• Clear impact statement tied to observable effect.

Output Contract

{
  "confirmed_findings": [],
  "disputed_findings": [],
  "inconclusive_findings": [],
  "evidence": [],
  "confidence": []
}

Failure Modes

• Single-shot confirmation without retest.
• Treating error differences as exploit proof.
• Claiming impact without business-context validation.

Exit Criteria

• Every finding has final status and explicit reason.
• Confirmed findings include replayable impact proof.
• Inconclusive findings list unblockers.

Detailed Operator Notes

Reproducibility Standard

• Replay each confirmed case in a fresh session.
• Replay with at least one payload or transport variant.
• Keep one negative control request for every positive claim.

False-Positive Controls

• For timing signals, compare against matched control payloads.
• For authz signals, verify with ownership-correct and ownership-incorrect objects.
• For parser signals, verify semantic effect, not just error shape changes.

Severity Calibration Inputs

• Required attacker privilege.
• Cross-tenant or single-tenant impact.
• Ability to automate at scale.
• Degree of data sensitivity.

Reporting Rules

• Include exact request signatures (method, path, key headers, payload hash).
• Include verification run count and consistency notes.
• Include why alternative explanations were rejected.

Conditional Decision Matrix

Advanced Coverage Extensions

1. Add negative-object tests for soft-deleted or archived resources.
2. Add replay-window tests for idempotency and duplicate processing.
3. Add bulk endpoint abuse tests for partial authorization failures.
4. Add asynchronous job handoff checks for stale permission snapshots.
5. Add pagination/filter abuse checks for hidden data exposure.