Built-in float scalar used in output 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 unconstrained Float in output position can lead to:

• Precision inconsistencies across clients
• Rounding errors in financial or critical calculations
• Exposure of unexpected or extreme values
• Leaking of internal computation details
• Contract instability when backend implementations change

For example, returning raw floating-point values for financial data may expose intermediate precision that is not intended for clients. In some cases, very large or unexpected values may signal logic flaws or computation errors.

A domain-specific scalar makes output semantics explicit and enables enforcing:

• Minimum and maximum bounds
• Precision constraints
• Business-meaningful ranges

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 contract clarity, reduces ambiguity across services, and strengthens auditability.