Common Exploit Verification

# Exploit verification report: IDOR on order endpoint

**ID:** IDOR-ORDERS-001  
**Vulnerability:** CWE-639: Authorization Bypass Through User-Controlled Key  
**Platform:** Backend API  
**Component:** `GET /api/v1/orders/{id}`  
**Severity:** High (CVSS: 8.1, provisional; recalculate if the validated data or privileges differ)  
**OWASP:** API1:2023 – Broken Object Level Authorization

## Proof of concept

**Preconditions:** Two ordinary accounts, Alice and Bob; Alice owns order `ORDER_B`; Bob owns `ORDER_A`; both have valid bearer tokens; no administrative privileges are used.

1. Authenticate as Alice and request Alice’s own order:

   ```sh
   curl -i -sS -H "Authorization: Bearer $ALICE_TOKEN" \
     "$TARGET/api/v1/orders/ORDER_A"
   ```

   Expected: `200 OK` with Alice’s order data.

2. While still authenticated only as Alice, replace the object ID with Bob’s order:

   ```sh
   curl -i -sS -H "Authorization: Bearer $ALICE_TOKEN" \
     "$TARGET/api/v1/orders/ORDER_B"
   ```

   Actual validated result: `200 OK` returns Bob’s order record instead of `403 Forbidden` or `404 Not Found`.

3. Repeat with a fresh Alice token and a second Bob-owned order to rule out cache or stale-session behavior. Preserve redacted response bodies, request IDs, timestamps, and ownership records showing that `ORDER_B` belongs to Bob.

**Payload:** `ORDER_B`—a valid object identifier belonging to another non-privileged user.  
**Evidence:** The validated cross-tenant response must include the actual status code and a redacted field comparison, for example: response owner/user ID = Bob, authenticated subject = Alice. Do not include live tokens or unnecessary personal/order data in the report.

## Impact

**Impact:** Any authenticated user who can discover or guess an order ID can read another customer’s order information. Depending on the returned fields, this may expose addresses, contact details, payment metadata, shipment data, or purchased items.

**Blast radius:** All orders reachable through predictable, leaked, or enumerated IDs across user or tenant boundaries. If equivalent authorization is absent on order update, cancel, download, or invoice endpoints, the same root cause may permit modification or further disclosure; test those separately and avoid duplicating the finding when the root cause is identical.

## Validation and false-positive disposition

This is confirmed because the two-account differential demonstrates unauthorized object access, not merely a missing middleware annotation or scanner result. Verify that Alice is not an administrator, that Bob’s ownership is authoritative in the database, and that no intentional sharing/ support role applies. If those conditions do not hold, downgrade to conditional or discard the finding.

## Remediation

Enforce ownership or tenant authorization in the data-access operation, using the authenticated principal from the server-side session—not a user ID supplied by the client. For example:

```sql
SELECT *
FROM orders
WHERE id = $1
  AND owner_user_id = $2;
```

Bind `$1` to the route ID and `$2` to the authenticated subject. Return the same not-found response for both nonexistent and unauthorized IDs where appropriate, to reduce enumeration. Apply the same policy to every order action, add regression tests asserting Alice receives no Bob-owned object, and log denied cross-object access without recording secrets or sensitive payloads.