Pattern for string schema is too loose
Issue ID: v3-schema-string-loosepattern
Average severity: Medium
This issue ID and article have been deprecated and will be removed.
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",
"operationId": "addPet",
"requestBody": {
"description": "Pet to add to the store",
"required": true,
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/NewPet"
}
}
}
}
},
// ...
"NewPet": {
"type": "object",
"description": "JSON defining a Pet object",
"additionalProperties": false,
"required": [
"name"
],
"properties": {
"name": {
"type": "string",
"pattern": ".*"
}
}
}
}Possible exploit scenario
If you define too loose pattern for strings, you do not actually limit what is accepted as the input. This could open your backend server to various attacks, like SQL injections or buffer overflows.
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 get passed to your API.
For example, the API below only accepts UUIDs that are compliant with RFC 4122:
{
"post": {
"description": "Creates a new pet in the store",
"operationId": "addPet",
"requestBody": {
"description": "Pet to add to the store",
"required": true,
"content": {
"application/json": {
"schema": {
"$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 ^ and $ in your regular expression, otherwise the overall length of the pattern is infinite.
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 |
|
— |