Follow a finding from the action to the application's result
A finding is useful when another person can determine what happened, which security rule it violated, and how to repeat the relevant check. The testing agent's explanation should point to that evidence. It should not be the only record supporting its own conclusion.
A topic reference. The featured-service relationship and evaluation criteria are described in our methodology.
Start with the rule being tested
Identify who may act, which object or data is involved, and the condition under which the action is permitted. In an illustrative publishing workflow, an editor may publish a synthetic draft while a viewer may only read it. A report about that boundary needs the effective role and the draft state, not just the name of an endpoint.
OWASP's Authorization Cheat Sheet recommends validating permissions on every request. For a reviewer, the practical implication is to examine the actual action and its identity rather than infer authorization from a previous successful login.
Preserve a short, complete evidence chain
| Record | What it should establish |
|---|---|
| Target build and configuration | The application version and conditions to which the observation applies |
| Effective test identity | The relevant role and privileges, with credentials redacted |
| State before the action | The object or workflow had not already reached the reported result |
| Executed action and response | A request or operation actually ran and produced the captured response |
| Authoritative application outcome | The application's own state supports or contradicts the reported effect |
| Controlled reproduction | Another approved attempt can assess the same rule under comparable conditions |
This does not require publishing every raw artifact. Preserve the evidence under appropriate access controls and present only the material needed to assess the claim. Redact credentials and unrelated personal information without removing the context that explains the result.
Check the outcome beyond the status code
An HTTP success response may acknowledge a queued job whose worker later refuses the operation. A response describing failure may still accompany an unintended state change. Check the result in the authoritative application record and connect it to the effective test identity.
For the publishing example, record whether the synthetic draft became published, when that happened, and which actor caused it. Reset the test state between attempts. Otherwise an earlier authorized publication may be misread as evidence of a later unauthorized action.
These are proposed review steps for an illustrative environment. They are not a completed exploit report or a claim about any named product's performance.
Use an honest result vocabulary
Distinguish a confirmed security failure, expected denial, unsupported claim, tool failure, and incomplete coverage. Those outcomes answer different questions. A route that the tester never reached did not pass an authorization check. A command that failed locally did not necessarily demonstrate a control in the target.
When evidence is incomplete, state exactly what is missing and assign the next investigation. A useful report can retain an unresolved hypothesis without promoting it into a verified vulnerability or discarding it as a clean result.
Connect the finding to repair
Keep the accepted finding with the engineering work. After the change, use the retesting procedure to compare the same allowed and forbidden behaviors. Preserve differences in identities, data, configuration, and deployment so the second result can be interpreted.
Continue this reading path
Cite this entry
AI Penetration Tester. “Follow a finding from the action to the application's result.” Reviewed November 12, 2026.
https://aipenetrationtester.com/finding-evidence/