Insufficient object-level access control
A normal authenticated user can change an identifier and retrieve an object owned by another account. The finding was manually validated in the agreed test context.
SAMPLE CUSTOMER-FACING AUDIT RESULT
This fictional example shows exactly what the customer receives: clear business impact, technical confirmation, remediation guidance for the client team and a separate status after repeat testing.
A normal authenticated user can change an identifier and retrieve an object owned by another account. The finding was manually validated in the agreed test context.
HOW TO READ A FINDING
These four blocks give the customer one connected answer: what happened, why it is possible, how important it is and what to do next.
The endpoint accepts an object identifier but the server does not verify ownership for the current user. Route, role, environment and prerequisites are recorded.
An authenticated user changes the identifier and reaches another account object. The scenario is documented step by step without unnecessary harmful actions.
Customer-data confidentiality, service trust and personal-data processing are at risk. Affected assets and roles are listed separately.
The scenario is available to a normal account, needs no admin rights and may affect many objects sharing the same access logic.
Concise impact on business, data, customers and obligations.
Exact conditions, reproduction, root cause and guidance.
Priority, action owner and a verifiable status after changes.
GUIDANCE & REPEAT TESTING
We document root cause and remediation guidance. The client or an agreed contractor implements changes; then we separately repeat the original scenario.
Authorization is enforced for every object and never trusts the client identifier. Foreign objects must receive the same safe denial.
Role and ownership rules live in a shared layer rather than being copied across endpoints, reducing inconsistent behavior.
The client team adds cross-account, cross-role and cross-organization tests, including adjacent API methods.
After changes, we repeat the original request and nearby variants, then record closed, partially closed or still exposed.
WHAT THE CUSTOMER RECEIVES
Not just a finding page, but connected material for decisions, remediation and closure control.
Overall risk, critical scenarios, affected processes and priorities.
Validated findings with conditions, impact, evidence and guidance.
Status, priority, asset and owner of the next action.
Safe request, response and context excerpts without unnecessary secrets.
Closed, partially closed or still exposed.
Report review, questions and clarification of technical guidance.