A vulnerability title is not an impact statement

A label can describe a class of weakness. It cannot, by itself, establish the impact of a particular instance. “Broken access control” names a concern; it does not tell the reader which user accessed which object, under which conditions, or with what consequence.

Keep three layers separate

1. Observation: the behavior directly present in the evidence.
2. Demonstrated consequence: what that behavior allowed within the authorized test.
3. Open question: a plausible extension that has not been established.

A precise report makes those layers visible rather than allowing a strong title to stand in for the missing chain between them.

A fictional example

An authenticated user receives an order belonging to a second test user. That can support a bounded cross-account read finding. It does not automatically establish account takeover, changes to credentials, deletion of orders or access to every record.

Ask four questions before the summary is final

• Can another authorized reviewer identify the affected role, object and control boundary?
• Does the recorded evidence support the stated consequence?
• Are untested conditions and exclusions stated explicitly?
• Does the remediation address the demonstrated control failure, with a measurable closure check?

Write the next check, not a guarantee

“Fixed” needs a basis. A retest should identify the build, scope, roles and behavior checked, alongside the remaining exclusions. It is a bounded result, not proof that the entire application is secure.

The same discipline helps the initial report. You can be direct about a serious weakness without claiming more than the evidence supports.

Further reading: OWASP Web Security Testing Guide | Reporting. This note is an original explanation; OWASP is an independent reference, not an endorsement.