Pattern for string schema in a response is too loose
Issue ID: v3-schema-response-string-loosepattern
Average severity: Medium
Description
The pattern for a string schema is too loosely defined. It does not actually limit what gets passed to the API.
For more details, see the OpenAPI Specification.
Example
The following is an example of how this type of risk could look in your API definition. The defined pattern is so loose that the API effectively accepts any string of any size and value:
{
"post": {
"description": "Creates a new pet in the store",
// ...
"responses": {
"200": {
"description": "success",
"schema": {
"type": "object",
"$ref": "#/components/schemas/NewPet"
}
}
}
},
// ...
"NewPet": {
"type": "object",
"required": [
"name"
],
"additionalProperties": false,
"properties": {
"name": {
"type": "string",
"pattern": ".*"
}
}
}
}Possible exploit scenario
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.
Remediation
Set a well-defined regular expression that matches your requirements in the pattern field of string parameters. This ensures that only strings matching the set pattern are accepted.
For example, the API below only accepts UUIDs that are compliant with RFC 4122:
{
"post": {
"description": "Creates a new pet in the store",
// ...
"responses": {
"200": {
"description": "success",
"schema": {
"type": "object",
"$ref": "#/components/schemas/NewPet"
}
}
}
},
// ...
"NewPet": {
"type": "object",
"description": "JSON defining a Pet object",
"additionalProperties": false,
"required": [
"name"
],
"properties": {
"name": {
"type": "string",
"maxLength": 10,
"pattern": "^[A-Za-z0-9]{3,10}$"
}
}
}
}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:
- Language-agnostic information on regular expressions at Base Definitions page on regular expressions
- OWASP Validation Regex Repository
- RegExr, an online tool for building and testing regular expressions
The following are examples of regular expressions for some common elements:
| Element | Examples of regular expressions | Examples with escape |
|---|---|---|
| Alphanumeric string |
|
— |
| Base64‑encoding (for an image) |
|
^data:image\\/(?:gif|png|jpeg|bmp|webp)(?:;charset=utf-8)?;base64,(?:[A-Za-z0-9]|[+/])+={0,2}$
|
| Date and time |
|
|
| Duration |
|
^\\d+:\\d{2}:\\d{2}$
|
| Email address (common format) |
|
^([a-z0-9_\\.-]+)@([\\da-z\\.-]+)\\.([a-z\\.]{2,5})$
|
| File |
|
|
| IP address |
|
|
| Numbers |
|
|
| Password constraints |
Password that has:
|
^(?=.*[0-9])(?=.*[a-z])(?=.*[A-Z])(?=.*[*.!@$%^&(){}[]:;<>,.?/~_+-=|\\]).{10,64}$
|
| Phone number |
International phone number, country code optional: 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@:%_\\+.~#?&//=]*)$
|
| UUID |
|
— |