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

Issue ID: graphql-data-input-custom-scalar-string-needed

Average severity: Critical

Description

The schema uses a built-in scalar of the type String instead of domain-specific and constrained custom scalar.

For more details, see the GraphQL specification.

Possible exploit scenario

The GraphQL String scalar accepts any UTF-8 text of arbitrary length. It does not define:

  • Maximum length
  • Minimum length
  • Allowed character set
  • Structural format
  • Encoding expectations
  • Domain semantics

As a result, a String in input position represents the broadest and least constrained attack surface in a GraphQL API. Without explicit constraints, a built-in String may enable:

  • Injection attacks (SQL, NoSQL, LDAP, command injection)
  • Excessive payload size leading to memory or CPU exhaustion
  • Unicode normalization and encoding inconsistencies
  • Business logic bypass (unexpected characters or control sequences)
  • Downstream parser abuse
  • Cross-layer deserialization issues

Because String is so permissive and widely used, unconstrained usage in input positions significantly increases the risk of exploitable conditions. This is what makes this a critical issue.

Remediation

Replace built-in String with constrained custom scalars that explicitly define validation rules. We recommend that you:

  • Define domain-specific scalars such as:
    • Email
    • Username
    • PhoneNumber
    • URL
  • Always enforce:
    • Maximum length
    • Pattern constraints where applicable
  • Avoid using the generic String for:
    • Identifiers
    • Security-sensitive values
    • Structured formats
    • Business-critical parameters

Explicit validation at the schema boundary improves data quality, reduces injection risk, strengthens contract clarity, and enables deterministic security auditing and scanning.