GraphQL Vulnerabilities Bug Bounty 2026 — Introspection, Batching and BOLA in Modern APIs | Bug Bounty Course Day 34 of 60

This article teaches bug bounty hunters how to identify, test, and report vulnerabilities in GraphQL APIs, focusing on three high-impact attack classes: introspection-based schema discovery, broken object-level authorization (BOLA), and batching attacks that bypass rate limiting. The material emphasizes safe, authorized testing practices and provides concrete techniques for mapping API attack surfaces, validating authorization failures using controlled accounts, and writing reproducible vulnerability reports.

• GraphQL endpoints and introspection differences from RESTUnlike REST APIs with multiple routes and response structures, GraphQL typically uses a single endpoint (commonly /graphql) that returns only the fields the client requests. If introspection is enabled, a single query can map the entire API schema—including types, fields, arguments, and mutations—without consulting separate documentation. The article emphasizes that enabled introspection is an information source, not automatically a vulnerability; actual risk depends on whether authorization controls prevent unauthorized access to exposed fields.
• Identifying and confirming GraphQL endpointsGraphQL endpoints appear as POST requests with JSON bodies containing a 'query' property, often at paths like /graphql, /api/graphql, or /gql. Confirmation is straightforward: send a test query such as {__typename} and look for a GraphQL response indicating the data type. The article notes that GET-based GraphQL exists but is less common. Finding these endpoints begins with Burp Proxy history during normal application browsing rather than blind scanning.
• BOLA testing methodology using two controlled accountsTo test broken object-level authorization safely, the article prescribes a specific process: authenticate as Account A and record the response when querying your own data, then substitute a different user's ID (from a second test account you control) and observe whether the server returns that other user's data. If it does, authorization has failed. The impact is amplified in GraphQL because a single query can request multiple related fields—profile, orders, payment metadata, messages—all of which may be exposed if the resolver tree lacks consistent authorization checks.
• Batching attacks and rate limit bypass mechanicsGraphQL servers may accept an array of operations in a single HTTP request for performance. If rate limiting counts only incoming HTTP requests and not individual operations within a batch, a single request containing many operations consumes just one request slot. The article demonstrates this with OTP verification: a 10-operation batch might be submitted as one HTTP request, allowing an attacker to test 10 codes in the time a single-operation rate limit would allow one. Safe PoC requires a small batch on an authorized lab, not a full brute-force attempt.
• Introspection disabled schema discovery through error messagesWhen introspection is blocked, the article introduces the technique of 'clairvoyance'—submitting queries with intentionally wrong field names and reading the error messages, which often suggest correct field names and reveal schema structure. This inference approach treats error responses as leads to investigate further rather than definitive schema maps, and should only be used on authorized targets.
• GraphQL injection and resolver-level input handlingGraphQL syntax does not prevent injection; the vulnerability lies in how resolvers handle arguments. An argument passed to a resolver may be inserted into a raw database query or system command without safe parameterization, introducing SQL or NoSQL injection. The article advises testing string arguments with injection characters (such as ' OR '1'='1) and watching for database errors, unexpected data returns, or stack traces that reveal backend structure.
• BOLA remediation requires resolver-level authorization checksThe article stresses that endpoint-level authentication alone is insufficient; authorization must be checked inside each resolver that accepts an object ID. The fix is to verify that the authenticated user's ID matches the requested object or that the user has explicit permission to access it. Field-level authorization middleware (such as graphql-shield) can help enforce these checks consistently across multiple resolvers, addressing the root cause rather than treating symptoms.
• Writing minimal, reproducible vulnerability reportsThe article provides a template showing that effective reports include the exact query, the specific field or mutation affected, the two test accounts used, a redacted response proving the unauthorized access, and enumeration or ID guessing details. For batching, include the mutation name, 5–10 example batched operations, and the response showing a successful match. Remediation advice must be specific to the root cause—for BOLA, authorize at the resolver level; for batching, enforce limits per operation as well as per HTTP request.

Bottom line: GraphQL vulnerabilities are discovered through systematic mapping of the API schema (via introspection or error inference), testing authorization at the object level using controlled accounts, and validating how rate limits interact with batching. Effective bug bounty reports require reproducible proof of concept queries and remediation advice matched to the underlying vulnerability mechanism, not generic fixes.