Sample penetration testing report: see it before you scope

Description

The invoices API returns any invoice by its numeric ID without checking that the invoice belongs to the caller’s organization. IDs are sequential, so every invoice can be reached by counting. The notes endpoint on the same resource is missing the same check.

Impact

Any customer with a login can read every other customer’s invoices, including billing contacts, addresses, line items and totals. They can also add notes that Example Corp staff see on those invoices. Testing stayed within the two test organizations Example Corp set up.

Evidence

GET /api/v2/invoices/48213 HTTP/1.1
Host: api.example.com
Authorization: Bearer [token for user A, organization 1001]

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 48213,
  "organization_id": 1002,
  "bill_to": "[redacted]",
  "total": "[redacted]",
  "status": "paid"
}

Steps to reproduce

1. 1Sign in as user A (organization 1001) and open one of your own invoices. Note the request to /api/v2/invoices/{id}.
2. 2Send the same request with the ID of an invoice that belongs to organization 1002 (48213 in testing).
3. 3The API returns the other organization’s invoice with 200 OK. A PATCH to /api/v2/invoices/48213/notes with user A’s token also succeeds and adds a note to it.

Remediation

Check ownership on the server for every request that takes an object ID: load the invoice, compare its organization_id with the caller’s organization, and return 404 when they differ. Apply the same check to the notes endpoint and every other route that takes an ID. Add an automated test that requests another organization’s objects and expects 404. Random IDs help as defense in depth, but they are not the fix.

References

OWASP API Security Top 10 (2023), API1: Broken Object Level Authorization. CWE-639: Authorization Bypass Through User-Controlled Key.