Built-in float 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

Using a custom scalar — typically paired with validation directives such as @numberValue(min:, max:) or an equivalent mechanism — makes these constraints explicit in the API contract, improves consistency across teams, and enables security tooling (like API Security Audit and API Scan) to deterministically reason what inputs are acceptable.