Testing GraphQL for Common Vulnerabilities

Hello! Welcome to your lesson on advanced web and API security.

In our last session, we explored how implementation flaws in the OAuth 2.0 protocol can be exploited to achieve account takeover. We focused on the state parameter for CSRF protection and the critical importance of a securely configured redirect_uri.

Today, we continue our journey into API security by examining GraphQL, a powerful and flexible query language for APIs that has become increasingly popular in modern web and mobile applications. While GraphQL offers developers significant advantages over traditional REST APIs, its complexity introduces unique and often severe security vulnerabilities.

This lesson will equip you to meet the learning outcome: Test GraphQL endpoints for common vulnerabilities like information disclosure via introspection and batching attacks. We will move from discovering an API's entire structure to leveraging its own features against it for high-impact results.

1. What is GraphQL and Why Does it Matter for Security?

Before we attack it, let's understand what makes GraphQL different. Unlike REST, where you have multiple endpoints each returning a fixed data structure (e.g., /users/1, /posts/12), a GraphQL API typically exposes a single endpoint. The client specifies exactly what data it needs in a single request, preventing the common problems of over-fetching (getting too much data) or under-fetching (needing to make multiple requests).

Your background in computer science will make the concept of a query language for an API intuitive. The key security implication is that this flexibility shifts significant power to the client. An attacker who can submit arbitrary GraphQL queries can potentially ask for more data than a developer ever intended to expose.

2. Information Disclosure via Introspection

The most critical first step in testing a GraphQL endpoint is to understand its schema. The schema is the blueprint of the entire API—it defines every possible query, every data type, and every action (called a "mutation") that the API supports.

Many GraphQL servers have a built-in feature called introspection, which allows you to query the schema itself. When enabled in a production environment, it's like handing an attacker the architectural plans to your entire application.

The standard introspection query is quite long, but it's a well-known payload that you can use to ask the server to describe itself.

Reporting that "introspection is enabled" is a low-impact finding. The real skill, and what separates beginners from experts, is analyzing the disclosed schema to find high-impact vulnerabilities.

As you saw in the video, the process is:

1. Run the introspection query to get the full schema.
2. Search the schema for interesting keywords like "admin", "internal", "password", "key", etc.
3. Identify a query or mutation that looks sensitive (e.g., adminDump).
4. Find the object type that this query returns (e.g., userInternal).
5. Examine the fields of that object type for sensitive data (e.g., passwordHash, apiKey).
6. Craft a new query to execute the sensitive operation and request the sensitive fields.

{
  "name": "getInvoice",
  "args": [
    {
      "name": "invoiceId",
      "type": { "name": "ID" }
    }
  ],
  "type": {
    "name": "Invoice",
    "kind": "OBJECT"
  }
}

{
  "name": "Invoice",
  "kind": "OBJECT",
  "fields": [
    { "name": "id" },
    { "name": "amount" },
    { "name": "status" },
    { "name": "customerDetails" }
  ]
}

query {
  getInvoice(invoiceId: "42") {
    id
    amount
    status
    customerDetails
  }
}

What if Introspection is Disabled?

In a hardened environment, introspection will be disabled. However, GraphQL's helpful nature can still be abused. The field suggestion feature, which suggests correct field names when you make a typo, can be used to enumerate the schema piece by piece.

For example, sending a query for a non-existent field like { users { nam } } might return an error like: Cannot query field "nam" on type "User". Did you mean "name"?

This error-based leakage allows an attacker to guess and confirm valid field names, slowly reconstructing the schema.

3. Denial of Service via Batching Attacks

GraphQL allows clients to "batch" multiple operations into a single HTTP request. This is done by sending a JSON array of query objects instead of a single object.

This feature can be abused in two primary ways:

1. Bypassing Rate Limiting: If rate limiting is implemented at the HTTP request level (e.g., "100 requests per minute"), an attacker can use batching to send thousands of logical operations (like login attempts or OTP guesses) in a single request, completely bypassing the security control.

2. Denial of Service (DoS): If a specific query is known to be resource-intensive (e.g., a complex data search or a system maintenance task), an attacker can send a batch of hundreds of these queries at once. The server will try to process all of them, potentially exhausting its CPU or memory and becoming unavailable to legitimate users.

The key takeaway is that if you find any way to bypass authentication or cause high resource usage with a single GraphQL query, you can almost always amplify its impact dramatically using a batching attack.

Conclusion

GraphQL is a double-edged sword: its flexibility is a boon for developers but a goldmine for attackers if not secured properly. As a penetration tester or bug bounty hunter, understanding its unique attack surface is non-negotiable.

Key Takeaways:

• Introspection is a Treasure Map: An enabled introspection endpoint is your highest priority discovery. It provides a complete roadmap of the API's functionality.
• Analyze the Schema for Sensitive Operations: Don't just report that introspection is on. Analyze the schema to find hidden or admin-only queries/mutations and craft exploits to access sensitive data or functionality.
• Abuse Error Messages: If introspection is disabled, use field suggestions and other verbose errors to manually reconstruct parts of the schema.
• Batching Amplifies Impact: Batching attacks are a powerful technique to bypass request-based rate limiting or to cause a Denial of Service by chaining resource-intensive queries.

Next Lesson Preview:

In our final lesson for this module, we will explore one of the most creative and impactful aspects of hacking: vulnerability chaining. You will learn how to combine multiple, seemingly lower-risk vulnerabilities (like some we've already discussed) to create a critical path to compromise. This will directly address the learning outcome: Chain multiple web vulnerabilities (e.g., SSRF + Command Injection) to achieve a critical impact.