Security Finding Validation

Input

Validation Workflow

Step 1: Understand the Finding

• The vulnerability class (BFLA, BOLA, XSS, SQLi, SSRF, etc.)
• The specific claim being made (what authorization check is missing, what input is unsanitized, etc.)
• The affected endpoint and HTTP method
• The code location

Step 2: Analyze the Source Code

1. Read the vulnerable file at the specified line number and all supporting files
2. Trace the request flow from route registration through middleware to the handler
3. Verify the specific claim — does the code actually lack the described check?
4. Look for indirect protections (middleware, helpers, ORM constraints) the scanner may have missed
5. Confirm the vulnerable code path is reachable under the described conditions

Step 3: Live Validation (When Available)

proxy

1. Start reaper proxy scoped to the target domain
2. Authenticate (or have the user authenticate) as a legitimate user and capture a valid request to the vulnerable endpoint
3. Replay or modify the request to attempt the exploit described in the finding
4. Compare the response to expected behavior:
   • Does the unauthorized action succeed? (true positive)
   • Does the server reject it with 401/403/404? (false positive)
5. Capture the request/response pair as evidence using

   reaper get <id>

Step 4: Make Determination

• True Positive: The vulnerability exists and is exploitable. The code lacks the described protection and the endpoint is reachable.
• True Positive (Confirmed): Same as above, plus live testing demonstrated successful exploitation.
• False Positive: The vulnerability does not exist. Provide the specific reason (indirect protection found, code path unreachable, etc.).
• Inconclusive: Cannot determine without additional information. Specify what is needed.

Step 5: Report

1. Determination: True Positive, False Positive, or Inconclusive
2. Confidence: High, Medium, or Low
3. Evidence Summary: Key findings from code review and/or live testing
4. Code Analysis: Specific lines and logic that support the determination
5. Live Test Results (if performed): Request/response pairs demonstrating the behavior
6. Recommendation: Fix if true positive, close if false positive, gather more info if inconclusive

## Validation Result
- **Determination**: True Positive
- **Confidence**: High
- **Evidence**: Handler at routes/transfers.go:142 queries transfers by ID without checking ownership. No middleware or ORM-level constraint enforces user scoping.
- **Recommendation**: Add ownership check — include user_id in the WHERE clause.

Step 6: Persist Results

## Validation

Vulnerability Class Reference

VULNERABILITY_PATTERNS.md