Schema allows additional properties

Issue ID: schema-object-additionalproperties-true

Average severity: Medium

This issue ID and article have been deprecated and will be removed.

Description

The schema you have defined allows additional properties, either intentionally or unintentionally.

In JSON, by default, any object can also accept additional properties. OpenAPI Specification (OAS) v2 does not define this behavior, and the current tooling (such as parsers and codegen) does not support it. Instead, they only accept the value object for this property. Thus, it is not recommended to use Boolean values.

However, OAS v2 does support using additionalProperties to specify a schema to which the additional properties must conform.

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. In this case, the schema does not use any combining operations (so there is no need to allow additional properties) but additionalProperties is set to true:

{
    "post": {
        "operationId": "addPet",
        "parameters": [
            {
                "name": "pet",
                "in": "body",
                "description": "Pet to add to the store",
                "required": true,
                "schema": {
                    "type": "object",
                    "properties": {
                        "name": {
                            "type": "string"
                        },
                        "tag": {
                            "type": "string"
                        }
                    },
                    "required": [
                        "name"
                    ],
                    "additionalProperties": true
                }
            }
        ]
    }
}

Possible exploit scenario

If you do not clearly define the schema and you leave properties of a JSON payload empty, you effectively allow attackers to pass in any data. This means that you are opening your backend to various attacks, such as SQL injection.

This also lets attackers to try various unexpected inputs. Unexpected inputs may cause the backend server to crash or behave in an unexpected way. This in turn may cause the server to potentially leak stack trace that can be used for further attacks, or even data.

If no restrictions to the set of properties in the JSON payload are enforced, the API might also accept more fields than expected. The received payloads could be blindly transformed into an object and stored, overwriting sensitive internal data.

Remediation

The safest option is not to allow additional properties. If the schema does not use allOf at all, make sure you define all properties of the accepted JSON payload in the schema itself.

Do not use combining operations (allOf) for defining additional properties in API definitions following the OAS v2.

We recommend updating your API definition to follow the OAS v3, because it offers proper support for additionalProperties as Boolean, in addition to other improvements.

If you cannot update your API to OAS v3, use additionalProperties to provide the schema that you want to support:

{
    "definitions": {
        "Pet": {
            "type": "object",
            "properties": {
                "name": {
                    "type": "string"
                },
                "petType": {
                    "type": "string"
                }
            },
            "required": [
                "name",
                "petType"
            ],
            "additionalProperties": "#/definitions/Cat"    
        },
        "Cat": {
            "properties": {
                "furType": {
                    "type": "enum",
                    "enum": [
                        "short-haired",
                        "long-haired",
                        "curly",
                        "naked"
                    ],
                    "default": "short-haired"
                }
            }
        }
    }
}