Anatomy of a finding
A finding you
can follow.
Read the evidence. Reproduce the issue. Review the fix. Check it again.
Illustrative report using synthetic data and a reserved .test domain. No live application was tested.
One account. Someone else’s invoice.
A signed-in member can read an invoice from another workspace by changing its ID.
GET /api/invoices/inv_8421 HTTP/1.1 Host: demo.harbor.test Authorization: Bearer [workspace-a-token]
HTTP/1.1 200 OK
{
"workspace_id": "workspace_b",
"invoice_id": "inv_8421",
"total": 2400
}Why this matters
The API authenticated the member, but did not check whether the invoice belonged to that member’s workspace. Authentication answers “who are you?” Authorization still needs to answer “can you read this?”
Assessed severity
CVSS v3.1: 6.5 (Medium). Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. This sample assumes a logged-in attacker and a high confidentiality impact, with no demonstrated change to data or availability.
Fix the boundary, then retest it
Resolve the invoice within the caller’s server-verified workspace. Add tests for cross-tenant reads and confirm that authorized users can still access their own invoices.
Ship the fix. Check it holds.
Give rootscan a login. Get back to building.