Built-in integer scalar used in input instead of a custom scalar

Possible exploit scenario

Numeric built-in scalar types Int and Float can handle basic data validation. While it ensures that the value is numeric and within a technical range (for example, between −2³¹ and 2³¹−1), they do not express the constraints that matter for application security and robustness, such as:

• Allowed range (min and max):
  • Prevent extreme values that could cause logic errors or overflows (for example, in prices, quantities, latitude or longitude)
  • Prevent extreme values that could trigger expensive processing paths (such as extreme values used in filtering, ranking, or scoring)
• Minimum or maximum business constraints
• Domain semantics distinguish between conceptually different numbers (like price, percentage, latitude, weight) so that they do not get reused incorrectly
• Contextual usage rules

In real-world APIs, integers frequently represent:

• Pagination parameters (limit, offset, page)
• Quantities (quantity, count)
• Status codes
• Ranking or scoring values
• Index-based object access
• Privilege levels or role indicators

Without explicit constraints, built-in Int allows values that may:

• Trigger excessive resource consumption (for example, limit: 1000000)
• Cause logic errors (for example, negative quantities)
• Lead to integer overflow in downstream systems
• Bypass business validation assumptions
• Enable enumeration or indexing attacks

Using a custom scalar — typically paired with validation directives such as @numberValue(min:, max:) or an equivalent mechanism — improves the data definition quality by:

• Making the expected range, semantics, and other constraints explicit
• Reducing ambiguity
• Improving consistency across teams

It also allows validation to occur at the API boundary rather than inside the resolver logic, and it enables security tooling (like API Security Audit and API Scan) to deterministically reason what inputs are acceptable.