October 27, 2026

Chained Information Disclosure and Broken Object-Level Authorization Leading to Cross-Account Data…

Severity: High — P2 Status: Confirmed CWE: CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor Related CWE: CWE-862 —…

By Akash motkar

5 min read

Severity: High — P2 Status: Confirmed CWE: CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor Related CWE: CWE-862 — Missing Authorization Attack Vector: Network Privileges Required: Low User Interaction: None Impact: Confidentiality — High

1. Executive Summary

During an authenticated security assessment, a chained vulnerability was identified that allowed a standard user to access information belonging to another user.

The attack did not initially appear to be high severity. The first issue discovered was a low-impact information disclosure (P4) in an API response. The response exposed internal resource identifiers that were not required by the normal user interface.

Further investigation showed that these identifiers could be supplied to another API endpoint. The second endpoint failed to verify whether the authenticated user was authorized to access the requested resource, resulting in a P3-level broken object-level authorization issue.

By combining both weaknesses, it was possible to progress from a normal low-privileged account to unauthorized access to resources belonging to another account.

The complete attack chain was successfully reproduced using two controlled test accounts. No administrative credentials were required, no victim interaction was necessary, and the final API response contained data belonging to the second account.

The individual findings therefore represent a significantly lower risk when viewed independently, but the complete attack path results in a High/P2 security impact.

2. Real-World Attack Scenario

An attacker first registers or obtains a normal user account on the application.

The attacker has no administrative privileges and is not authorized to access information belonging to other users.

While using the application normally, the attacker observes an API response containing internal resource identifiers.

For example:

Attacker Account
       |
       v
Normal authenticated session
       |
       v
API response exposes resource ID
       |
       v
Attacker identifies another resource
       |
       v
Resource ID supplied to another API endpoint
       |
       v
Missing object-level authorization
       |
       v
Protected resource returned
       |
       v
Sensitive information belonging to another user exposed

The attack requires only a valid low-privileged account.

No administrator account, password reset, phishing, social engineering, or victim interaction is required.

3. Initial Discovery — P4 Information Disclosure

The assessment began with routine inspection of API traffic generated by the application.

While reviewing a legitimate request made by the standard user interface, the following endpoint was identified:

GET /api/v1/event/list HTTP/1.1
Host: target.example
Authorization: Bearer <ATTACKER_TOKEN>

The endpoint returned information associated with application resources.

The response contained an internal identifier:

{
  "events": [
    {
      "id": 18473,
      "resourceId": 55219,
      "status": "active"
    }
  ]
}

The resourceId was not required for the visible functionality being tested and appeared to reference an internal application object.

At this stage, the finding was considered low impact because possession of the identifier alone did not demonstrate unauthorized access.

The issue was therefore initially classified as:

P4 — Information Disclosure

However, the exposed identifier provided an interesting opportunity for further testing.

4. Pivot to the Resource API

During endpoint enumeration, another API endpoint was identified that accepted the previously observed identifier:

GET /api/v1/resource/55219 HTTP/1.1
Host: target.example
Authorization: Bearer <ATTACKER_TOKEN>

The endpoint appeared to retrieve the resource associated with the supplied ID.

The security-relevant question was therefore:

Does the application verify that the authenticated user is actually authorized to access resource 55219?

To answer this, two controlled accounts were created.

Account A — Low-privileged test account
Account B — Separate test account

A resource was created under Account B.

The resource identifier was then obtained through the previously identified information-disclosure condition.

5. Authorization Testing — P3

The resource belonged to Account B.

The tester then authenticated as Account A and submitted the following request:

GET /api/v1/resource/55219 HTTP/1.1
Host: target.example
Authorization: Bearer <ACCOUNT_A_TOKEN>
Accept: application/json

The expected result was:

HTTP/1.1 403 Forbidden

because Account A had no relationship with the resource.

Instead, the application returned:

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

with the resource belonging to Account B.

This confirmed that the backend was using the supplied resource identifier without sufficiently verifying the authorization relationship between the authenticated user and the requested object.

The second issue was therefore classified as:

P3 — Broken Object-Level Authorization / Missing Authorization

6. Complete Exploitation Chain

The complete attack path was then reproduced from beginning to end.

Step 1 — Obtain a normal account

The attacker authenticates using a standard user account.

No elevated privileges are required.

Step 2 — Access the API

The attacker accesses the API normally available to the authenticated user:

GET /api/v1/event/list

Step 3 — Obtain an internal resource identifier

The response discloses:

resourceId = 55219

This represents the P4 information-disclosure component.

Step 4 — Identify the resource owner

Testing with controlled accounts confirms that the resource belongs to a different account.

Resource: 55219
Owner: Account B
Attacker: Account A

Step 5 — Request the resource using Account A

The attacker sends:

GET /api/v1/resource/55219 HTTP/1.1
Authorization: Bearer <ACCOUNT_A_TOKEN>

Step 6 — Authorization check fails

Instead of rejecting the request, the backend returns:

HTTP/1.1 200 OK

Step 7 — Protected information is returned

The response contains information associated with Account B.

For example:

{
  "resourceId": 55219,
  "ownerId": 9281,
  "status": "active",
  "createdAt": "2026-10-21T10:14:32Z",
  "metadata": {
    "accountReference": "REDACTED",
    "contact": "REDACTED"
  }
}

This establishes the final security impact: Account A can access protected information belonging to Account B.

7. Why This Is a P2 Finding

If the first issue were reported independently, it would be considered P4 because the exposed identifier alone did not provide unauthorized access.

Likewise, the authorization weakness may initially appear to be P3 if exploitation requires knowledge of a valid resource identifier.

The combination changes the practical risk.

The first vulnerability provides the information necessary to identify resources.

The second vulnerability fails to enforce authorization on those resources.

Together, they create a complete attack path:

P4
Information Disclosure
       ↓
Internal Resource Identifier
       ↓
P3
Broken Object-Level Authorization
       ↓
Cross-Account Resource Access
       ↓
P2
Sensitive Information Disclosure

The final P2 classification is therefore based on the demonstrated end-to-end impact rather than simply combining the numerical severity levels.

8. Security Impact

An attacker with a normal application account could potentially access resources that belong to other users.

Depending on the information associated with the affected resource, exploitation could result in:

  • Cross-account information disclosure
  • Exposure of user-specific data
  • Exposure of internal account identifiers
  • Disclosure of confidential business information
  • Unauthorized access to tenant-specific resources
  • Privacy violations
  • Resource enumeration

If the same authorization weakness exists across additional API endpoints, the impact could extend beyond the specific resource demonstrated during testing.

The assessment should only claim the data exposure that was actually verified.

9. Attack Prerequisites

The attack requires:

Required:

  • A valid standard application account.
  • Network access to the affected API.

Not required:

  • Administrator credentials.
  • Another user's password.
  • Session theft.
  • Password reset.
  • Victim interaction.
  • Phishing.
  • Social engineering.
  • Client-side exploitation.

This makes the attack particularly relevant because the attacker can operate entirely through the application's exposed API.

10. Root Cause

The primary root cause is insufficient server-side object-level authorization.

The backend appears to determine which resource should be returned based primarily on the client-supplied identifier:

/resource/<resource_id>

without reliably enforcing:

Does authenticated_user have permission to access resource_id?

The application additionally exposes internal resource identifiers through an API response, making resource discovery easier.

Resource identifiers must therefore be treated as references, not authorization mechanisms.

Knowing or guessing an object ID must never be sufficient to obtain that object's data.

The application should implement strict server-side authorization for every protected object.

For every request, the backend should determine:

Authenticated User
        ↓
Requested Resource
        ↓
Ownership / Role / Tenant Relationship
        ↓
Authorization Decision

Only after the authorization check succeeds should the resource be returned.

For example:

GET /api/v1/resource/55219

should internally perform an authorization check equivalent to:

Is resource 55219 accessible by the authenticated principal?

If the answer is no, the application should return an appropriate authorization failure.

Additionally:

  1. Review all API endpoints accepting object identifiers.
  2. Implement centralized authorization middleware.
  3. Enforce tenant isolation where applicable.
  4. Remove unnecessary internal identifiers from API responses.
  5. Do not rely on unpredictable IDs as an authorization control.
  6. Test horizontal privilege boundaries systematically.
  7. Add automated authorization tests for cross-user resource access.
  8. Review similar endpoints for the same vulnerability pattern.

#cybersecurity #infosecurity #penetrationtesting #pentesting #VAPT #ethicalhacking #offensivesecurity #applicationsecurity #websecurity #APIsecurity #APIPentesting #BugBounty #VulnerabilityResearch #SecurityResearch #RedTeam #AppSec #OWASP #OWASPAPI #BOLA #IDOR #BrokenAccessControl #AccessControl #Authorization #InformationDisclosure #DataExposure #PrivilegeEscalation #VulnerabilityChaining #AttackChain #SecurityAssessment #CyberSecurityResearch #CVE #CVSS #RiskAssessment #SecurityTesting #WebApplicationSecurity #APIHacking #BugHunting #ResponsibleDisclosure #P2Vulnerability #HighSeverity #SecurityFindings