Why resolved is not validated, and the gate I run before I believe a finding

When I started auditing my own findings instead of submitting them on excitement, a meaningful fraction did not survive. Not edge cases. Things I had been about to report. The pattern was always the same: I had confused “the system returned data” with “I caused the system to do something it should not.” Those are different claims, and only one of them is a vulnerability.

”The API returned data” is not a bug

An endpoint returning your own data over an object ID is not a finding. It is an API. The bug is access to data that is not yours, demonstrated, from a context where you should not have it. Until you have shown the second half of that sentence, you have a screenshot of an HTTP 200, which is the most common false positive there is.

The same trap closes around “resolved.” A program marking your report resolved is a workflow state, not a verdict on your reasoning. Programs resolve things to clear a queue, to close a duplicate, to be polite, to ship a defensive change that was cheap regardless of whether your specific claim was correct. Treating resolved as proof you were right is how you accumulate a portfolio of findings you cannot actually defend. I validate before I submit, not after the program tells me what I want to hear.

Gate 1: reproduce from a clean state

Replay the finding from nothing. New browser profile, no cached session, no cookies, no extension, no leftover token from the recon I did an hour ago. Half of all “vulnerabilities” are an authenticated session you forgot you had. If the behavior only appears with the state your testing already accumulated, the state is the bug, and the bug is yours.

Gate 2: prove impact with a second pristine account

For anything about accessing data or actions across a boundary, one account proves nothing. I provision a second account, fresh, with its own data, that has never interacted with the first. Then I show account A reaching account B’s resource. If I cannot demonstrate the cross-boundary step with two accounts that have no shared history, I do not have an authorization bug. I have a hunch.

Gate 3: rule out that it was always yours

This is the gate that kills the most false positives, and the one people skip. Before claiming you accessed something you should not have, prove you did not own it to begin with. The object you “leaked” may have been created by your account, assigned to your tenant, or seeded into your workspace by onboarding. The ID looks foreign; the ownership is not. So I trace provenance: where did this resource come from, who created it, was it ever legitimately in my scope. If the honest answer is “it was always mine,” there is no finding, and submitting it anyway burns trust I do not get back.

Gate 4: survive a triager’s skim

The last gate is presentation, and it is a real gate because a correct finding that reads like noise gets closed as noise. A triager gives a report seconds on the first pass. If the impact is not legible in that skim, if the reproduction steps assume context they do not have, if the proof requires them to trust your narration instead of seeing the result, the report fails regardless of being technically right. I write so the load-bearing artifact, the exact request, the two-account diff, the data that should be unreachable, is visible without the reader reconstructing my session in their head.

The discipline is subtraction

None of this is about finding more. It is about believing less, faster. I run a finding through all four gates and assume it will fail one of them, because most do, and the cheapest place to catch a false positive is on my own machine before it has my name on it. Auditing a batch of “good” findings and watching a real fraction collapse under Gate 1 or Gate 3 is humbling the first time and routine after that. The hunters whose reports get believed on sight are not luckier. They have already thrown away everything that would not have survived.