/triage-validation

name: triage-validation
description: Finding validation before writing any report — 7-Question Gate (all 7 questions), 4 pre-submission gates, always-rejected list, conditionally valid with chain table, CVSS 3.1 quick reference, severity decision guide, report title formula, 60-second pre-submit checklist. Use BEFORE writing any report. One wrong answer = kill the finding and move on. Saves N/A ratio.

TRIAGE & VALIDATION

One wrong answer = STOP **this finding**. Kill **the finding**. Move on **to the next test class**.

> **Scope of "STOP" in this skill:** This skill's gates kill INDIVIDUAL FINDINGS that fail validation. They do NOT authorize stopping the engagement. Killing a finding via the 7-Question Gate just means *that finding* doesn't get submitted — every other test class in the engagement is still pending. See `redteam-mindset` "DO NOT STOP primary directive" for the coverage-axis rule.

> "N/A hurts your validity ratio. Informative is neutral. Only submit what passes all 7 questions."

---

THE 7-QUESTION GATE

Ask IN ORDER. One wrong answer = STOP immediately.

---

Q1: Can an attacker use this RIGHT NOW, step by step?

Complete this template:

1. Setup:   I need [own account / another user's ID / no account]
2. Request: [exact HTTP method, URL, headers, body — copy-paste ready]
3. Result:  I can [read / modify / delete] [exact data shown in response]
4. Impact:  The real-world consequence is [account takeover / PII read / money stolen]
5. Cost:    Time: [X minutes], Capital: [$0 / $X subscription required]

**If you CANNOT write step 2 as a real HTTP request → KILL IT.**

---

Q2: Is the impact on the program's accepted impact list?

Go to the program page. Find "Vulnerability Types" or "Out of Scope."

Common tiers:

• **Critical**: Any-user ATO without interaction, RCE, SQLi with data exfil, admin auth bypass
• **High**: Mass PII exfil, privilege escalation, internal SSRF with data, stored XSS all users
• **Medium**: IDOR on specific user non-critical data, XSS on sensitive page requiring click
• **Low**: Non-sensitive info disclosure, clickjacking with PoC

**If your bug maps to a listed exclusion → KILL IT.**

---

Q3: Is the root cause in an in-scope asset?

Confirm:

• Vulnerable domain is on the in-scope list (not `*.internal.target.com`)
• It's a production asset (not staging/dev unless explicitly in scope)
• It's not a third-party service the company just uses (not Stripe, Salesforce, Google Auth)

**If out-of-scope → KILL IT.**

---

Q4: Does it require privileged access that an attacker can't realistically get?

• "Admin can do X" = centralization risk = **KILL IT** (on 99% of programs)
• "Non-admin can do X that only admin should do" = valid
• "Requires physical access / MFA device" = usually invalid
• "Requires compromised victim account to work" = questionable, low severity at best

---

Q5: Is this already known or accepted behavior?

Search: 1. Program's HackerOne/Bugcrowd disclosed reports: Ctrl+F endpoint name + bug class 2. GitHub issues on target repo: `is:issue label:security ENDPOINT_NAME` 3. Changelog/CHANGELOG.md — does it mention this behavior? 4. API docs / design docs — is it documented as intended?

**If acknowledged/design decision → KILL IT.**

---

Q6: Can you prove impact beyond "technically possible"?

• XSS → show actual cookie theft or session hijack, not just `alert(1)` or `alert(document.domain)`
• SSRF → hit an internal endpoint that returns data, not just DNS ping
• SQLi → show actual data exfil from a real table, not just error message
• IDOR → show actual other-user's data in response, not just a 200 status code

**If you can only show "technically possible" → DOWNGRADE severity, not kill.**

---

Q7: Is this a known-invalid bug class?

Check the NEVER SUBMIT list below. If it's on this list without a chain → **KILL IT.**

---

THE LAYER-ORDERING TRAP — read before claiming any auth bypass

**A validation error does NOT prove you passed authentication.**

This is the highest-confidence false positive in the auth-bypass class, because the evidence looks concrete. The reasoning that fails:

> "I sent an unauthenticated request and got back `400 — field X is required`. > A validation error means the request cleared auth and reached business logic. > Therefore auth is missing."

That inference is only valid if auth runs *before* input handling. Many stacks put a **global input sanitiser, body parser, or schema filter in front of the auth middleware.** A malformed body is then rejected before auth is ever consulted, and the response is indistinguishable from "auth passed, validation failed."

**The test: re-send with a minimal WELL-FORMED body.**

# malformed body — trips the sanitiser, which runs FIRST
curl -s -X POST https://target/api/v1/resource -d '{'
# 400 {"code":"ERR-INPUT-0001","message":"Invalid text. Only permitted
#      characters are allowed"}                      <- looks like auth bypass

# same endpoint, well-formed empty object — now auth is reached
curl -s -X POST https://target/api/v1/resource -H 'Content-Type: application/json' -d '{}'
# 401 {"code":"ERR-AUTH-0001","message":"Not authenticated. Please log in."}

**Only the second response tells you where the auth layer sits.**

**Lesson from an authorized engagement.** On a production API, a malformed body returned a validation-shaped `400` on the large majority of endpoints tested. Read as an auth bypass, that is a Critical filed against production infrastructure covering financial and administrative operations. It was a sanitiser reacting to the `{` character before auth ran — every one of those endpoints returned `401` to a well-formed `{}`. The false Critical was avoided only because someone re-tested.

**Rules:**

• Layer ordering is not observable from a single response. Never infer it.
• Probe auth with the *simplest valid* body the parser will accept, not a malformed one.
• If the error text is about