Numeric scalar in input has no maximum defined

Issue ID: graphql-data-input-numeric-scalar-max-needed

Average severity: Medium

Description

A numeric scalar used in an input position has no maximum value specified. While GraphQL ensures the value is numeric (Int or Float), it does not enforce any business or operational bounds.

For more details, see the GraphQL constraints specification.

Possible exploit scenario

Without a defined maximum, clients may submit extremely large values that exceed intended application limits. Attackers could attempt to send large numeric values that:

  • Trigger excessive memory allocation
  • Cause expensive database queries
  • Force large result sets
  • Lead to performance degradation
  • Cause arithmetic overflows in downstream systems
  • Trigger an unhandled exception

If limit has no maximum bound, the backend may attempt to process or allocate resources beyond safe thresholds, which in turn could cause the backend server to fail in an unexpected way and open the door to further attacks. For example, the backend server could throw an exception and return a stack trace on the error. The trace could contain information on the exact software stack used in the implementation. This enables the attacker to launch an attack on specific vulnerabilities known in that stack.

In some cases, extremely large values may also cause unexpected type coercion or overflow when mapped to database types or external systems.

Even if the backend eventually rejects the input, repeated large payload submissions can contribute to Denial of Service (DoS and DDoS) conditions.

Remediation

Set both minimum and maximum or equivalent constraints for numeric scalars to limit the accepted values to the range that works for your application. We recommend that you:

  • Always define both min and max bounds
  • Keep maximum values aligned with the operational limits of the backend services
  • Apply stricter bounds to:
    • Pagination
    • Batch operations
    • Computational parameters
  • Avoid relying solely on resolver-level validation

Explicit numeric bounds improve application robustness, reduce abuse potential, and enable deterministic security auditing.