GraphQL Injections

Data query and manipulation language for APIs

Core Concepts

• Uses HTTP/HTTPS, typically over POST requests.

• JSON-based queries and responses.

• Typically uses a single endpoint for all operations.

• Apollo Server commonly uses port 4000 as its default when started without configuration.

• Express-based GraphQL servers frequently use port 3000, simply because that's the default for many Express setups.

• Introspection allows clients to query the API schema for available operations and data types.

Schema

Every GraphQL API has a schema that defines:

• Types - What objects exist

• Queries - How to READ data

• Mutations - How to WRITE/CHANGE data

Types

A Type defines the structure of an object:

type User {
  id: ID!
  email: String!
  role: String!
  inviteCode: String
  verified: Boolean!
}

This means:

• User is an object

• It has 5 fields: id, email, role, inviteCode, verified

• ! means required/non-null

• No ! means optional (can be null)

Queries

Queries are like GET requests in REST:

Schema Example

type Query {
  me: User
  systemStatus: String
  incidentReports: [IncidentReport]
}

Request Example

query {
  me {
    id
    email
  }
}

When a query returns an OBJECT type (like User), you must specify which fields you want. You can't just say me , you must say me { id email }

Mutations

Mutations are like POST/PUT/DELETE in REST:

Schema Example

type Mutation {
  login(email: String!, password: String!): User
  register(email: String!, password: String!): User
  regenerateInviteCode: User
}

Request Example

mutation {
  login(email: "[e-mail]", password: "pass123") {
    id
    email
    verified
  }
}

• login takes 2 arguments: email and password

• It returns a User object

• We specify which User fields we want back: id, email, verified

Introspection

introspection allow to query the schema itself.

If introspection is enabled in production, attackers can discover the entire API structure.

The GraphQL Request Format

Every GraphQL request has this structure:

{
  "query": "your GraphQL query here",
  "variables": { "optional": "values" }
}

Testing Checklist

Key GraphQL Security Issues

• Introspection in Production

• Over-fetching Sensitive Data

• Mutation Side Effects

• Test Query Depth and Complexity: Check server limits on nested or complex queries to prevent performance issues.

• Validate Input Types and Arguments: Test inputs with invalid data to identify validation weaknesses.

• Examine Query Aliasing and Batching: Test for data leaks via aliased queries and batched requests.

• Check for Introspection Misuse: Ensure introspection doesn't expose sensitive or unnecessary schema details.

• Assess Authorization Controls: Confirm proper enforcement of access controls for queries and operations.

• Evaluate Rate Limiting: Ensure the API handles excessive or malicious requests effectively.

• Fuzz Mutations: Test for security and validation flaws in mutation operations.

Introspection Queries

For Burp Suite, wrap the queries in JSON.

{"query": "PASTE_YOUR_RAW_GRAPHQL_HERE"}

Discovery

List all Queries

{ __schema { queryType { fields { name } } } }

List all Mutations

{ __schema { mutationType { fields { name } } } }

Intelligence Gathering

Get Query Descriptions, developers sometimes leave sensitive notes

{ __schema { queryType { fields { name description } } } }

Attack Preparation

Understand exactly what data you need to send to execute an attack

Lists mutations and reveals their Arguments (inputs) and the Type of data they expect:

{ __schema { mutationType { fields { name args { name type { name } } } } } }

• You cannot hack a mutation without knowing what arguments it accepts.

Lists every field inside a specific type (in this case, "User")

{ __type(name: "User") { fields { name } } }

• Once you find a query that returns a User, run this to see if it contains sensitive fields that you can request.

Response Analysis

Determine if you can dump data in bulk (Lists) or if you get detailed objects

Tells you what object a Mutation returns after it runs

{ __type(name: "Mutation") { fields { name type { name } } } }

• If a mutation returns a User object, you might be able to ask for private user data immediately after creating/updating them.

Drills down into complex types to see if they are Lists or Nullables to identify Bulk Dump vulnerabilities

{ __type(name: \"Mutation\") { fields { name type { name kind ofType { name kind ofType { name } } } } } }

• If you find a query that returns a type of kind: LIST (e.g., [User]), you can potentially ask for every user in the database in a single request, rather than just one.

Executing Mutations

Once you have found a Mutation name and its required Arguments, use these templates to attack it.

Mutation with NO Arguments

Use this when the mutation acts on the current logged-in user (like regenerateInviteCode or logout).

Since there are no inputs needed, you just list the fields you want back inside { }

{
  "query": "mutation { regenerateInviteCode { id email inviteCode } }"
}

Mutation with INLINE Arguments

Use this for simple mutations (like login or deleteUser) where you have hard-coded values.

Pass the arguments directly inside the parenthesis (...)

{
  "query": "mutation { loginUser(email: \"[e-mail]\", password: \"password123\") { token id } }"
}

• Remember to escape quotes (\") if you are inside a JSON string.

Mutation with VARIABLES

It separates the logic from the data, making it much easier to fuzz specific parameters.

{
  "query": "mutation ($email: String!, $pwd: String!) { loginUser(email: $email, password: $pwd) { token } }",
  "variables": {
    "email": "[e-mail]",
    "pwd": "password123"
  }
}

• The query part: Defines what you are doing and types of data (String!).

• The variables part: Contains the actual payload.