cordon-validate

Cordon validation

No PoC, no finding. A candidate becomes confirmed only through validate_findings, poc_record, or takeover_confirm. Nothing else can set that status.

The rule that governs every PoC

The smallest proof that settles the question.

Proving SQL injection means showing 1 AND 1=1 and 1 AND 1=2 differ, or that a SLEEP(5) delays the response. It does not mean dumping the users table. The extra step adds no evidence, converts a clean report into a data-handling incident, and is exactly what programs mean by "do not exfiltrate".

This is enforced, not advised: sqlmap's data-extraction flags (--dump, --dbs, --tables, --file-read) are absent from its argument allowlist. No approval can produce an extraction run.

Automatic validation

validate_findings(min_severity="medium")     # exploit mode, needs approval
xss_validate(url)                            # dalfox, verifies execution
sqli_validate(url)                           # detection only
oob_listener()                               # callback domain for blind classes

Validators run in parallel, one per vulnerability class. Each returns proven or not-proven with a reason. Not-proven downgrades the finding to needs_manual_review with that reason attached — which is a useful result, not a failure.

Classes that need a human, by design

Class	Why automation stops
IDOR / authz	Proving it means reading another user's data
Auth bypass	Proving it means being someone else
RCE	Proving it means executing code on their host
Blind SSRF	Needs an out-of-band listener and injection context

For these, reproduce by hand with the least impact that demonstrates the issue, then:

poc_record(
  finding_id=...,
  reproduction="GET /api/users/2 with user A's session cookie",
  expected_result="403 Forbidden",
  observed_result="200 OK returning user B's email address",
  impact_limit_note="Read one adjacent record to prove the flaw; nothing retained.",
)