Custom scalar in output is missing '@stringValue' or '@numberValue' directive, or equivalent

Possible exploit scenario

Custom scalars are frequently introduced to express domain-specific types. However, without an associated constraint or validation directive, a custom scalar typically does not provide:

• Enforceable or enforcable bounds (such as length or range)
• Format constraints (pattern)
• Consistent validation semantics across resolvers
• Does not provide deterministic guarantees to API consumers

In such cases, the custom scalar effectively behaves as a renamed built-in scalar (commonly a String), providing no enforceable contract improvement and creating a false sense of security

A type constraint directive is a GraphQL directive that declares a family of constraints applicable to a scalar category, for example:

• @stringValue:
  • Length
  • Pattern
  • Character restrictions (as supported)
• @numberValue:
  • Minimum or maximum values (and optionally precision rules, as supported), or equivalents provided by the chosen validation framework

For output values, missing constraints can lead to:

• Leaking unexpected or overly large values
• Inconsistent format guarantees across services
• Precision instability for numeric values
• Contract drift over time
• Increased exposure risk in federated environments
• Inability for automated tooling to validate response guarantees

Using a recognized type constraint directive allows expressing the expected serialization shape, explicit contract-level validation expectations, and other allowed characteristics of the scalar. This makes the API contract clearer, provides cross-service consistency, strengthens data governance controls, and allows automated auditing and conformance validation.

Because unconstrained custom scalars undermine the security and reliability benefits they are intended to provide — especially for input validation — this is a critical issue.