GraphQL Exploitation: Secondary Context Attacks and Business Logic

GraphQL exploitation presents a sophisticated challenge for security engineers, extending far beyond simple introspection queries. A particularly potent and often overlooked vulnerability class is the secondary context attack, which weaponizes the very architecture that makes GraphQL efficient. In many enterprise applications, GraphQL servers act as a Backend-for-Frontend (BFF), receiving a client request and then making a second, trusted request to an internal microservice or REST API. This internal hop is where the danger lies. If an attacker can control a parameter in the initial request—such as a field with a weak ID or String scalar type—they can manipulate the second request through techniques like path traversal, bypassing security controls and accessing sensitive internal endpoints. This guide, based on an expert talk by Willis Vandevanter, breaks down this attack pattern from first principles. You will learn a practical methodology for discovering and chaining these vulnerabilities for maximum impact, and master the defensive strategies needed to build resilient, secure-by-default GraphQL APIs.

Understanding Secondary Context Attacks in BFF Architectures

Most modern GraphQL exploitation techniques leverage underlying architectural patterns, and one of the most critical to understand is the secondary context attack. This attack is particularly potent in applications that use a Backend-for-Frontend (BFF) design pattern, which is a common architectural choice for enterprise-level systems.

The Backend-for-Frontend (BFF) Pattern Explained

The BFF pattern involves an intermediate server that stands between the client-side front end and a collection of backend microservices or REST APIs. The core function of the BFF is to aggregate data and handle logic specific to a particular front-end experience (e.g., a web app vs. a mobile app).

The critical security implication of this pattern is that it creates a two-step request flow:

1. Primary Context (Untrusted Zone): The user’s client makes an initial request to the BFF. This request originates from an untrusted environment.
2. Secondary Context (Trusted Zone): The BFF processes the initial request and then makes a second, new request to an internal microservice or REST API. This second request originates from within the application’s trusted internal network.

For example, a client request to company.com/api/users/{userID} might cause the BFF to make an internal request to user.microservice/users/{userID}. The parameter from the first context is passed directly into the construction of the second.

How a Secondary Context Attack Works

A secondary context attack occurs when an attacker manipulates a controllable parameter in the primary request to maliciously alter the destination or behavior of the secondary request. The BFF is tricked into making a harmful request on the attacker’s behalf from within the trusted zone.

A common vector for this is path traversal. Consider this flow:

• An attacker identifies a controllable parameter, such as an id, in the initial API call.
• Instead of a legitimate ID, they submit a path traversal payload: ../../account/12919.
• The BFF, unaware of the malicious intent, takes this input and appends it to the internal API path, constructing a new URL like: user.microservice/users/../../account/12919.
• When the server normalizes this path, the .. characters navigate up the directory tree, and the final request targets a completely different endpoint: user.microservice/account/12919.

The attacker has successfully abused the BFF’s trust in user input to access a different “context”—the account endpoint instead of the intended user endpoint—potentially leading to vulnerabilities like Insecure Direct Object References (IDORs).

The Critical Factor: Relaxed Internal Authorization

This attack becomes especially powerful when authorization is relaxed or removed between the BFF and the internal microservices. Developers sometimes hard-code a high-privilege authorization token (like a JWT or static API key) at the BFF layer, assuming all internal communications are secure.

When an attacker performs a secondary context attack via path traversal, their malicious request to a different microservice inherits this hard-coded, high-privilege token. This can grant them access to highly sensitive services, such as payment or order APIs, that they could never have reached directly. This anti-pattern often arises when different development teams manage various microservices, each with its own threat model, leading to insecure blanket permissions being set at the BFF level.

Why GraphQL APIs are Prime Targets for Path Traversal

Effective GraphQL exploitation often begins by understanding and abusing the API’s underlying architecture. GraphQL servers are frequently implemented using the Backend-for-Frontend (BFF) design pattern, where the GraphQL server receives a client-side query and, in turn, makes a second, trusted request to an internal REST API or microservice. This two-hop process creates the perfect entry point for secondary context attacks. The initial GraphQL query represents the primary context, which an attacker can control, and the subsequent internal API call is the secondary context, which can be manipulated.

When the GraphQL server improperly handles input from the primary context, it opens the door for an attacker to influence or control the request made in the secondary context. If an attacker can inject a path traversal payload into a GraphQL input field, they can trick the BFF into targeting a completely different and potentially unauthorized internal endpoint, leading to a classic GraphQL path traversal vulnerability.

The Root Cause: Insecure GraphQL Scalar Types

A common misconception is that GraphQL’s strong typing system inherently prevents such injection attacks. However, the root of this vulnerability lies within two of GraphQL’s five default scalar types: String and ID.

• String Scalar: This type accepts any valid string, providing no built-in sanitization. As a result, a field expecting a simple string will also accept a path traversal payload like ../api/v1/accounts as valid input.

• ID Scalar: This is the most critical and often overlooked vector. According to the official GraphQL documentation, the ID type “serializes the same as string” and merely signifies that the value is “not intended to be human-readable.” It does not enforce a specific format like a UUID or integer. Therefore, an input field of type ID is functionally identical to a String and will readily accept a path traversal payload.

This behavior is a critical weakness. When a developer uses a default ID scaler for a field like accountId, they may implicitly trust that GraphQL will only permit valid identifiers. In reality, the server will accept a malicious string, append it to the internal REST API path, and inadvertently allow the attacker to control the destination of the trusted, secondary request. This makes any query or mutation using these insecure GraphQL scalar types a high-priority target for security testing.

A Methodology for Discovering and Exploiting GraphQL Vulnerabilities

A systematic approach is crucial for effective GraphQL exploitation, especially when targeting complex vulnerabilities like secondary context attacks. This methodology provides a repeatable framework for security engineers to discover and chain vulnerabilities, moving from initial fingerprinting to full exploitation. The core of this process involves identifying insecure input handling, confirming control over backend API calls, and leveraging that control to pivot to other internal endpoints.

Phase 1: Fingerprinting and Initial Reconnaissance

The first step is to identify a GraphQL endpoint and gather as much information as possible about its schema.

• Fingerprinting: A reliable method for discovering GraphQL servers, even across a large set of hosts, is to send a POST request with a malformed query. Many servers respond with verbose validation errors that uniquely identify them as GraphQL endpoints, which can be more effective than sending standard introspection queries that might be blocked.
• Schema Discovery:
  • Introspection: If enabled, this is the most straightforward way to get the full schema.
  • Client-Side Review: In Single Page Applications (SPAs), it’s common for queries, mutations, and schema fragments to be hardcoded in client-side JavaScript. Tools like Burp Suite’s BChecks can be used to statically analyze JS files and reconstruct parts of the schema.
  • Suggestions: Some servers provide “Did you mean…?” suggestions for guessed object names. A tool like Clairvoyance automates this process to rebuild the schema when introspection is disabled.
  • Brute-Forcing and Error Analysis: If the above methods fail, the last resort is to brute-force common object and field names. The goal is to trigger validation errors that leak information. As seen in the case study, an error might disclose required input types or, even better, the full path of the internal REST API endpoint the resolver is trying to contact (e.g., apiv1/context).

Phase 2: Identifying Vulnerable Inputs

The entry point for a GraphQL path traversal attack is almost always an input field that uses one of GraphQL’s weakly-validated default scalar types.

• Focus on Insecure GraphQL Scalar Types: The ID and String scalar types are functionally identical and accept any string value, including path traversal payloads (../). They offer no built-in validation. When you see a query or mutation that accepts an ID as input, it should be treated as a major red flag and an immediate target for testing.
• Tool-Assisted Discovery: To efficiently find these targets while walking an application, use tooling to highlight requests with these scalar types. A Bambdas script in Burp Suite can create a custom proxy filter or column that flags any request containing (ID:, (id:, or (string:. This allows you to quickly spot potentially vulnerable operations among the high volume of traffic from modern web apps.

Phase 3: Confirming Path Control

Once a suspicious input is identified, the next step is to confirm that you can actually control the path of the secondary request.

1. Fuzz for Reflection: Replace the expected input (e.g., a UUID) with a simple, unexpected string like “not-real-id” or “test”. Look for an error message (often a 404 Not Found) that reflects your input at the end of a URL path (e.g., microservice/api/v1/accounts/not-real-id). This confirms that your input is being appended to the path of the internal request.
2. Confirm Path Traversal: Send a classic GraphQL path traversal payload like ../test. If the server responds with an error showing a normalized path (e.g., microservice/api/v1/test), you have confirmed the ability to break out of the intended directory.
3. Map the API Root: To understand the boundaries of your attack, recursively add ../ segments to your payload until the server response changes, typically to a 400 Bad Request. This usually indicates you have reached the root of the file system or web server, defining the scope of your traversal.
4. Bypass WAFs: Remember to try different URL encodings for the traversal payload (e.g., ..%2f) to bypass WAFs or other input filters.

Phase 4: Chaining for Exploitation

A confirmed path traversal is not the final exploit; it’s the primitive used to reach other vulnerabilities. The impact comes from chaining it with another piece of information or weakness.

• Chaining with Information Disclosure: In one case study, error-based brute-forcing revealed an internal endpoint (/api/v1/query) vulnerable to SQL injection but with no direct input. The path traversal vulnerability in a different query (contact) was used to pivot and send a payload to this hidden endpoint, achieving blind SQL injection.
• Chaining with IDOR: In another example, a direct IDOR was impossible because the API path was scoped to the current user (/api/me/accounts/{account_id}). By using path traversal (../../users/{other_user_id}/accounts/{other_user_id}), the attacker broke out of the /me/ scope and accessed an endpoint that lacked proper authorization checks, successfully retrieving another user’s account data. This was possible because the authorization token was likely hard-coded at the BFF, granting the request broad internal permissions.

Case Study 1: Chaining Path Traversal and Info Disclosure for Blind SQL Injection

1. Initial Reconnaissance and Information Disclosure: The target was a GraphQL API with introspection disabled. The first step involved sending queries for guessed object names (e.g., client) without required sub-fields. This intentionally caused a validation failure, which leaked information about the expected query structure, confirming the existence of valid objects.

2. Discovering a Latent SQLi Endpoint via Brute-Forcing: By brute-forcing common object names, an interesting error was triggered for the object contact. The error message disclosed the full backend REST API call, revealing a highly sensitive internal endpoint: API/V1/query. The error also leaked the parameters for this endpoint, which were table and cql (a SQL query string). However, the GraphQL contract query itself accepted no input, making this SQL injection point unreachable directly.

3. Identifying Path Traversal in a Separate Query: Concurrently, another GraphQL query, contact, was found to accept a contactID as input. Fuzzing this input with a simple string like not real ID produced an error showing the input value was being directly appended to the backend URL path.

4. Confirming Path Control: To confirm a GraphQL path traversal vulnerability, the contactID was set to a traversal payload like ../../Test. The server’s error response confirmed the backend request was made to API/V1/test, proving that the attacker could control the directory and endpoint being called in this secondary context attack.

5. Chaining Vulnerabilities for Exploitation: The final exploit chained the two previously discovered vulnerabilities. The contact query’s path traversal (Step 4) was used as a carrier to target the latent, uncontrollable SQL injection endpoint found via the contract query (Step 2).

6. Executing a Blind SQL Injection: The contactID input was crafted with the payload ../../API/V1/query?[BLIND_SQLI_PAYLOAD]. The SQL injection had to be blind (e.g., time-based) because the GraphQL server expected to receive a contact object from the backend. If the backend REST API returned a 200 OK response with SQL results, the GraphQL layer would see a type mismatch, discard the data, and return null to the client. By using timing attacks, the attacker could exfiltrate data from the database despite the mismatched response structure, achieving a critical impact.

Case Study 2: Exploiting a GraphQL Path Traversal for Cross-Account Data Access (IDOR)

This case study demonstrates a chained GraphQL exploitation flow, combining a path traversal vulnerability within an ID scalar type with an Insecure Direct Object Reference (IDOR) to achieve cross-account data access.

1. Identify the Target Query: The attacker identifies a GraphQL query, getAccountById, which uses a GUID as an accountID to retrieve the current user’s private account data. The schema likely defines this input using the ID scalar type.
2. Fuzz Input to Confirm Path Injection: To test for a secondary context attack, the attacker replaces the expected GUID with an unexpected string like fake_uuid. The server responds with a 404 Not Found error, which importantly discloses the backend REST API path structure: microservice/api/v1/me/accounts/fake_uuid. This confirms the user-controlled accountID is being appended to an internal API path.
3. Verify Path Traversal Vulnerability: The attacker submits a simple GraphQL path traversal payload, ../test, as the accountID. The backend path normalizes to .../api/v1/me/test, demonstrating that the attacker can successfully escape the intended /accounts/ directory.
4. Chain Path Traversal with IDOR: An attempt to directly access another user’s data by providing their accountID fails because the backend path is scoped to the current user via /me/. The final exploit chains the vulnerabilities:
   • The attacker leaks a second user’s GUID from another part of the application.
   • A malicious path traversal payload is crafted for the accountID field. Based on the backend path structure, the payload is constructed to navigate up from the /me/accounts/ directory and reconstruct a path to the target user’s data, such as ../../users/{VICTIM_GUID}/accounts/.
5. Achieve Unauthorized Data Access: The GraphQL server processes the malicious input, makes a request to the manipulated backend path, and successfully retrieves the victim’s account data. This confirms that the GraphQL server, acting as a BFF, was likely using a hardcoded authorization header for internal requests, which the attacker inherited through the path traversal.

Key Tools:

• Clairvoyance: An automation tool used to discover a GraphQL schema by guessing objects and interpreting “Did you mean…?” suggestions when introspection is disabled.
• BChecks: Tools used for static analysis of client-side JavaScript to find hardcoded GraphQL queries, mutations, or schema fragments, aiding in schema reconstruction.
• Bambdas: A Burp Suite feature for writing custom filters to highlight interesting HTTP requests, such as those containing GraphQL queries with vulnerable ID or String scalar types.

Defensive Strategies: Secure GraphQL Development and Mitigation

Effectively defending against advanced GraphQL exploitation techniques, like secondary context attacks, requires a proactive, secure-by-default mindset that goes beyond reactive fixes. The root of many path traversal vulnerabilities lies in GraphQL’s own design, specifically with its default scalar types. Understanding and addressing these architectural weaknesses is the key to building resilient APIs.

The Problem with Default ID and String Scalar Types

A core vulnerability enabler for GraphQL path traversal is the overly permissive nature of the default ID and String scalar types. The GraphQL specification itself notes that the ID type “serializes the same as string,” merely signifying that it’s not intended to be human-readable. It performs no inherent format validation.

This means that from the GraphQL server’s perspective, both a legitimate UUID ("a1b2c3d4-...") and a path traversal payload ("../../api/v1/users/123") are perfectly valid inputs for a field typed as ID. This lack of built-in validation for insecure GraphQL scalar types forces the responsibility of sanitization and validation onto downstream services, which may not have the context to do so correctly, creating a significant security gap.

Adopt Custom, Type-Safe Scalers for Inherent Security

The most robust defense is to enforce strict type safety at the schema level itself. Instead of relying on generic String or ID types, developers should use precise, custom scalers. A highly recommended approach is to use a library like graphql-scalars, which provides pre-built, secure types for common data formats.

Key benefits of this approach include:

• Proactive Validation: By defining a field with a UUID scaler, any input that is not a valid UUID is rejected at the GraphQL layer before it can ever be passed to a backend microservice. This prevents path traversal payloads by design.
• Improved Threat Modeling: A descriptive schema enhances security reviews. If a security engineer sees a field using a URL scaler, it immediately signals the need to test for Server-Side Request Forgery (SSRF) and other URL-based vulnerabilities.
• Incremental Adoption: Implementing custom scalers doesn’t require an immediate, full-scale refactor. Teams can adopt them incrementally—a “crawl, walk, run” approach—to progressively harden their GraphQL schema.

While an alternative mitigation, like using encodeURIComponent at the BFF/proxy layer, can prevent some path traversal, it’s a reactive fix. Adopting type-safe scalers is a “secure by default” architectural choice that fundamentally eliminates the vulnerability class.

The Danger of Hard-Coded Authorization at the Proxy

One of the most dangerous patterns that amplifies the impact of a secondary context attack is hard-coding authorization at the BFF or proxy layer. In this anti-pattern, the BFF receives a request from a client, and then adds a static, high-privilege authorization header (like a master API key or a service-to-service JWT) before forwarding the request to an internal microservice.

If an attacker can achieve path traversal, they don’t just control the request’s destination—they also inherit the powerful, hard-coded authorization token. This allows them to make authenticated requests to completely different microservices (e.g., payment or order services) as a trusted internal component, bypassing all user-level access controls. Security engineers must treat the presence of hard-coded credentials at the proxy as a critical risk that must be investigated and remediated.

Detection and Monitoring for Defenders

Because exploiting these vulnerabilities often involves significant probing—sending numerous requests with path traversal payloads to map out internal endpoints—it creates a detectable footprint. Defenders have a valuable opportunity to identify this activity by monitoring backend services for an abnormal spike in 404 Not Found or 503 Service Unavailable errors. Setting up alerts in observability platforms like DataDog for unusual error rates can serve as an early warning system for an ongoing attack.

Key Tools:

• graphql-scalars: A defense-focused library providing custom, type-safe GraphQL scalers (e.g., UUID) to enforce stricter input validation directly at the schema level, preventing insecure inputs.

FAQ

What is a secondary context attack?

A secondary context attack occurs in architectures like Backend-for-Frontend (BFF) where a server receives a request and then makes a second request to an internal service. The attack happens when an attacker manipulates a parameter in the first request (e.g., a user ID) to control the destination or behavior of the second, trusted internal request, often via path traversal.

Why is the GraphQL ID scalar type so dangerous?

The default GraphQL ID type is dangerous because it provides no format validation. It serializes just like a String, meaning it will accept any text as valid input, including path traversal payloads (../../..). Developers often mistakenly assume it only accepts identifiers like UUIDs, creating a critical security blind spot.

How can I defend my GraphQL API against these attacks?

The most effective defense is to adopt a “secure by default” approach. Replace the generic ID and String scalar types with precise, custom types (e.g., UUID, Email) using a library like graphql-scalars. This enforces strict validation at the schema level. Additionally, avoid hard-coding high-privilege authentication tokens at the BFF/proxy layer to prevent privilege inheritance.

How do I find these vulnerabilities during a penetration test?

Start by identifying all GraphQL queries and mutations that use ID or String inputs. Fuzz these inputs with unexpected strings to see if they are reflected in backend error messages. If so, test for path traversal payloads (../test) to confirm you can control the internal request path. Use tools like Bambdas to automatically highlight these requests during testing.

Conclusion

Secondary context attacks represent a significant and often underestimated threat to modern applications, especially those leveraging GraphQL in a BFF architecture. The seemingly benign ID and String scalar types create an open door for path traversal, enabling attackers to pivot within a trusted network and chain vulnerabilities for devastating impact.

For offensive security engineers, this attack vector offers a rich area for exploration, rewarding a methodical approach that combines error-based reconnaissance with creative vulnerability chaining.

For defenders, security cannot be an afterthought. Proactive measures, such as adopting type-safe custom scalers and eliminating hard-coded credentials at the proxy layer, are essential to building resilient, secure-by-default systems. By understanding both the offensive methodology and the defensive patterns, teams can effectively mitigate this advanced GraphQL exploitation technique.

Tools & Other References:

• graphql-scalars
• Clairvoyance
• BChecks
• Bambdas
• OWASP API Security Top 10