String scalar in output has no pattern defined

Issue ID: graphql-data-output-string-scalar-pattern-needed

Average severity: Critical

Description

A string scalar used in an output position has no pattern defined. While GraphQL guarantees that a value is a string, it does not define any structural or semantic format.

For more details, see the GraphQL constraints specification.

Possible exploit scenario

Without a pattern or equivalent constraint, the API contract does not explicitly specify the expected format of returned values.

String inputs frequently represent structured data, such as email addresses, usernames, or URLs. If no pattern constraint is defined, the API may return:

  • Unexpected formats
  • Internal system values
  • Corrupted or injected content
  • Values leaking implementation details
  • Data inconsistent with documented behavior

Attackers strive to make your APIs behave in an unexpected way to learn more about your system or to cause a data breach. Good data definition quality in the schemas used in API responses allows reliably validating that the contents of outgoing API responses are as expected.

While filtering API responses does not block a specific kind of attack, it is there as a damage control mechanism in the unfortunate event that a successful attack has been conducted: it allows blocking the response and prevent attackers from retrieving data they should not access.

In the vast majority of cases (with the notable exception of Denial of Service (DoS and DDoS) attacks) attacks are conducted because attackers want to access data or resources they should not have access to. Often, this means that the structure or the size of the API response changes as a result of a successful attack, compared to a normal API response.

Validating that API responses are as expected can be achieved through proper schema validation of the API responses. The accuracy of this depends on the quality of the response schemas: the better defined your schemas are, the easier it is to detect when something is not right.

In security-sensitive environments, clearly defined output formats serve two important purposes:

  • Contract enforcement: Consumers can rely on predictable formats.
  • Damage containment: If a backend component is compromised or misconfigured, schema-level constraints help detect abnormal or malicious output before it propagates.

If a backend service is compromised or incorrectly implemented, it may return:

  • Internal file paths
  • Stack trace fragments
  • Raw database keys
  • Malformed identifiers

For example, if a field is expected to return a UUID but instead returns a database primary key, stack trace fragment, or injected string, a pattern constraint would make this deviation detectable. Without a defined output pattern constraint:

  • The deviation may go unnoticed
  • Monitoring systems may fail to detect anomalies
  • Downstream systems may process unexpected data
  • Sensitive information may be exposed

In federated GraphQL environments, lack of format constraints may also introduce inconsistencies across subgraphs, increasing the risk of cross-service ambiguity and data leakage.

Because structured output values often represent security-relevant identifiers or sensitive metadata, missing format constraints significantly weakens the API contract and is therefore a critical issue.

Remediation

Define a strict pattern constraint for structured string scalars in output. This ensures that only strings matching the set pattern are exposed through your API. We recommend that you:

  • Define patterns for all structured string types
  • Prefer whitelist-style regular expressions (allowed characters) over blacklist rules
  • Keep patterns aligned with business requirements
  • Avoid overly permissive patterns such as .*

Explicit structural constraints strengthen API contract integrity, improve anomaly detection, and reduce unintended data exposure.

We recommend that you carefully think what kind of regular expression best matches your needs. Do not simply blindly copy the pattern from the code example.

Remember to include the anchors ^ and $ in your regular expression, otherwise the overall length of the pattern could be considered infinite. If you include the anchors in the regular expression and the pattern only has fixed or constant quantifiers (like {10,64}, for example), you do not have to define the property maxLength separately for the object, as the length is fully constrained by the pattern. However, if the regular expression does not include the anchors or its quantifiers are not fixed (like in ^a.*b$), it can be considered to be just a part of a longer string and the property maxLength is required to constrain the length.

For more information on regular expressions, see the following:

The following are examples of regular expressions for some common elements:

Element Examples of regular expressions Examples with escape
Alphanumeric string
  • String with spaces: ^[a-zA-Z0-9 ]*$
  • String without space ^[a-zA-Z0-9]*$
 —
Base64‑encoding (for an image)

^data:image\/(?:gif|png|jpeg|bmp|webp)(?:;charset=utf-8)?;base64,(?:[A-Za-z0-9]|[+/])+={0,2}$

^data:image\\/(?:gif|png|jpeg|bmp|webp)(?:;charset=utf-8)?;base64,(?:[A-Za-z0-9]|[+/])+={0,2}$
Date and time
  • Date as YYYY-MM-DD, only - as separator: ^([12]\d{3}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01]))$
  • Date as DD-MM-YYYY, with /, -, or . as separator: ^(?:(?:31(\/|-|\.)(?:0?[13578]|1[02]|(?:Jan|Mar|May|Jul|Aug|Oct|Dec)))\1|(?:(?:29|30)(\/|-|\.)(?:0?[1,3-9]|1[0-2]|(?:Jan|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec))\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:29(\/|-|\.)(?:0?2|(?:Feb))\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\d|2[0-8])(\/|-|\.)(?:(?:0?[1-9]|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep))|(?:1[0-2]|(?:Oct|Nov|Dec)))\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$
  • Date as DD-MM-YYYY, with /, -, or . as separator, checks for leap years: ^(?:(?:31(\/|-|\.)(?:0?[13578]|1[02]))\1|(?:(?:29|30)(\/|-|\.)(?:0?[1,3-9]|1[0-2])\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:29(\/|-|\.)0?2\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\d|2[0-8])(\/|-|\.)(?:(?:0?[1-9])|(?:1[0-2]))\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$
  • Time as HH:MM, 24-hour clock, leading 0: ^(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]$
  • Time as HH:MM, 12-hour clock, leading 0 optional, AM/PM: ^((1[0-2]|0?[1-9]):([0-5][0-9]) ?([AaPp][Mm]))$
  • Time as HH:MM:SS, 24-hour clock: ^(?:[01]\d|2[0123]):(?:[012345]\d):(?:[012345]\d)$
  • Date as YYYY-MM-DD, only - as separator: ^([12]\\d{3}-(0[1-9]|1[0-2])-(0[1-9]|[12]\\d|3[01]))$
  • Date as DD-MM-YYYY, with /, -, or . as separator: ^(?:(?:31(\\/|-|\\.)(?:0?[13578]|1[02]|(?:Jan|Mar|May|Jul|Aug|Oct|Dec)))\\1|(?:(?:29|30)(\\/|-|\\.)(?:0?[1,3-9]|1[0-2]|(?:Jan|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec))\\2))(?:(?:1[6-9]|[2-9]\\d)?\d{2})$|^(?:29(\\/|-|\\.)(?:0?2|(?:Feb))\\3(?:(?:(?:1[6-9]|[2-9]\\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\\d|2[0-8])(\\/|-|\\.)(?:(?:0?[1-9]|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep))|(?:1[0-2]|(?:Oct|Nov|Dec)))\\4(?:(?:1[6-9]|[2-9]\\d)?\\d{2})$
  • Date as DD-MM-YYYY, with /, -, or . as separator, checks for leap years: ^(?:(?:31(\\/|-|\\.)(?:0?[13578]|1[02]))\\1|(?:(?:29|30)(\\/|-|\\.)(?:0?[1,3-9]|1[0-2])\\2))(?:(?:1[6-9]|[2-9]\\d)?\d{2})$|^(?:29(\\/|-|\\.)0?2\\3(?:(?:(?:1[6-9]|[2-9]\\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1\\d|2[0-8])(\\/|-|\\.)(?:(?:0?[1-9])|(?:1[0-2]))\\4(?:(?:1[6-9]|[2-9]\\d)?\\d{2})$
  • Time as HH:MM, 24-hour clock, leading 0: ^(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]$
  • Time as HH:MM, 12-hour clock, leading 0 optional, AM/PM: ^((1[0-2]|0?[1-9]):([0-5][0-9]) ?([AaPp][Mm]))$
  • Time as HH:MM:SS, 24-hour clock: ^(?:[01]\\d|2[0123]):(?:[012345]\\d):(?:[012345]\\d)$
Duration

^\d+:\d{2}:\d{2}$

^\\d+:\\d{2}:\\d{2}$
Email address (common format)

^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,5})$

^([a-z0-9_\\.-]+)@([\\da-z\\.-]+)\\.([a-z\\.]{2,5})$
File
  • File path: ^((\/|\\|\/\/|https?:\\\\|https?:\/\/)[a-z0-9 _@\-^!#$%&+={}.\/\\\[\]]+)+\.[a-z]+$/
  • File name, with 3-letter extension: ^[\w,\s-]+\.[A-Za-z]{3}$
  • File path: ^((\\/|\\\\|\\/\\/|https?:\\\\\\\\|https?:\\/\\/)[a-z0-9 _@\\-^!#$%&+={}.\\/\\\\\\[\\]]+)+\\.[a-z]+$/
  • File name, with 3-letter extension: ^[\\w,\\s-]+\\.[A-Za-z]{3}$
IP address
  • IPv4: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$
  • IPv6: ^(([0-9a-fA-F]{1,4}:){7,7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:)|fe80:(:[0-9a-fA-F]{0,4}){0,4}%[0-9a-zA-Z]{1,}|::(ffff(:0{1,4}){0,1}:){0,1}((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])|([0-9a-fA-F]{1,4}:){1,4}:((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9]))$
  • IPv4: ^(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$
  • IPv6: ^(([0-9a-fA-F]{1,4}:){7,7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:)|fe80:(:[0-9a-fA-F]{0,4}){0,4}%[0-9a-zA-Z]{1,}|::(ffff(:0{1,4}){0,1}:){0,1}((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])|([0-9a-fA-F]{1,4}:){1,4}:((25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9])\\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[0-9]){0,1}[0-9]))$
Numbers
  • Positive whole numbers: ^\d+$/
  • Negative and positive whole and decimal numbers: ^-?\d*(\.\d+)?$
  • Positive whole numbers: ^\\d+$/
  • Negative and positive whole and decimal numbers: ^-?\\d*(\\.\\d+)?$
Password constraints

Password that has:

  • At least 10 but no more than 64 characters
  • At least one digit
  • At least one lowercase letter
  • At least one uppercase letter
  • At least one special character

^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[*.!@$%^&(){}[]:;<>,.?/~_+-=|\]).{10,64}$

^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[*.!@$%^&(){}[]:;<>,.?/~_+-=|\\]).{10,64}$
Phone number

International phone number, country code optional: ^(?:(?:\(?(?:00|\+)([1-4]\d\d|[1-9]\d?)\)?)?[\-\.\ \\\/]?)?((?:\(?\d{1,}\)?[\-\.\ \\\/]?){0,})(?:[\-\.\ \\\/]?(?:#|ext\.?|extension|x)[\-\.\ \\\/]?(\d+))?$

Use libraries instead or regular expressions to validate phone numbers whenever possible.

 ^(?:(?:\\(?(?:00|\\+)([1-4]\\d\\d|[1-9]\\d?)\\)?)?[\\-\\.\\ \\\\\\/]?)?((?:\\(?\\d{1,}\\)?[\\-\\.\\ \\\\\\/]?){0,})(?:[\\-\\.\\ \\\\\\/]?(?:#|ext\\.?|extension|x)[\\-\\.\\ \\\\\\/]?(\\d+))?$
URL/URI (with protocol optional)

^(https?:\/\/)?(www\.)?[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)$

^(https?:\\/\\/)?(www\\.)?[-a-zA-Z0-9@:%._\\+~#=]{2,256}\\.[a-z]{2,6}\\b([-a-zA-Z0-9@:%_\\+.~#?&//=]*)$
UUID

^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89AB][0-9a-f]{3}-[0-9a-f]{12}$

—