Example SaaS Platform

Affected endpoint

PATCH /api/v1/users/{userId}

Required access

Any authenticated Standard User

Classification

OWASP API3:2023 / CWE-915

CVSS 3.1 vector

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

What was found

The profile-update endpoint accepted the privileged role property from a Standard User. The server wrote that value directly to the user record and issued an updated session containing the administrator role. The user interface did not expose this field, but hiding it in the browser did not provide server-side protection.

Attack path reproduced

1. The assessor signed in with the Standard User account [email protected].
2. A legitimate profile-name update was intercepted in the browser.
3. The assessor added "role":"platform_admin" to the JSON body.
4. The API returned 200 OK and stored the new role without an authorization check.
5. The same account then opened the administrator export endpoint and received tenant data.

PATCH /api/v1/users/usr_demo_1048 HTTP/1.1
Host: api.demo.example
Authorization: Bearer [redacted]
Content-Type: application/json

{
  "displayName": "A. Tester",
  "role": "platform_admin"
}

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

{
  "id": "usr_demo_1048",
  "displayName": "A. Tester",
  "role": "platform_admin"
}

GET /api/v1/admin/customers/export HTTP/1.1
Authorization: Bearer [same user session]

HTTP/1.1 200 OK
Content-Type: text/csv
[response body redacted]

Business impact

Any compromised or malicious customer account could become a platform administrator. In the tested version this exposed customer exports and administrative functions, affecting confidentiality, integrity and availability across tenant boundaries.

Root cause

A general-purpose user model was bound directly to client-controlled JSON. The endpoint did not use an allowlist of editable profile fields, and administrator routes trusted the stored role without recording how it had been assigned.

Recommended fix

• Use a dedicated self-service profile DTO that does not contain role or permission fields.
• Allow role changes only through a separate administrative operation with explicit authorization.
• Enforce authorization centrally on every administrator route and deny access by default.
• Audit role changes with actor, target, previous value, new value and request identifier.
• Invalidate existing sessions when privileges change and add negative authorization tests.

Affected endpoint

GET /api/v1/invoices/{invoiceId}

Required access

Authenticated user in any tenant

Classification

OWASP API1:2023 BOLA / CWE-639

CVSS 3.1 vector

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

What was found

Invoice records were retrieved by their identifier without checking that the invoice belonged to the caller's tenant. While authenticated as Tenant Alpha, changing one identifier returned an invoice owned by Tenant Beta, including customer name, billing address, line items and payment status.

GET /api/v1/invoices/inv_demo_1048
Authorization: Bearer [Alpha session]

HTTP/1.1 200 OK
{ "tenantId": "tenant_alpha", ... }

GET /api/v1/invoices/inv_demo_1053
Authorization: Bearer [same Alpha session]

HTTP/1.1 200 OK
{ "tenantId": "tenant_beta", ... }

Root cause and recommended fix

The data lookup used only invoiceId. Scope every query to the authorized tenant and object, for example by selecting on both tenantId from the trusted session and invoiceId. Apply the same policy to download, update, delete and export routes. Unpredictable identifiers are useful defense in depth, but are not authorization.