OWASP API security – 6: Mass assignment

Introduction

1: Broken object level authorisation

2: Broken user authentication

3: Excessive data exposure

4: Lack of resources & rate limiting

5: Broken function level Authorization

6: Mass assignment

7: Security misconfiguration

8: Injection

9: Improper assets management

10: Insufficient logging & monitoring


 

The mass assignment vulnerability is a lack of data input validation that allows an attacker to modify data or elevate privileges by manipulating payload data.  In the case of an object database, for example, if the payload maps directly to the stored data and is inserted directly, without input validation compared against authorisation levels, then the attacker can craft a payload that alters data not intended to be altered.

To prevent against mass assignment APIs need to validate input against a blacklist or preferably a whitelist so that only the expected fields of the payload are evaluated, coupled with authorisation validation to ensure the client has the correct privileges on those fields.  This ensures that data can only be modified by a client that is granted the rights to modify that data.

OWASP summary

Threat agents/attack vectors Security weakness Impacts
API specific : Exploitability 2 Prevalence 2 : Detectability 2 Technical 2 : Business specific
Exploitation usually requires an understanding of the business logic, objects’ relations, and the API structure. Exploitation of mass assignment is easier in APIs, since by design they expose the underlying implementation of the application along with the properties’ names. Modern frameworks encourage developers to use functions that automatically bind input from the client into code variables and internal objects. Attackers can use this methodology to update or overwrite sensitive object’s properties that the developers never intended to expose. Exploitation may lead to privilege escalation, data tampering, bypass of security mechanisms, and more.

Source: OWASP mass assignment

APIM context

While, in general, mass assignment is an API issue to solve an APIM can facilitate the process.  Validation of the payload through, for example, a JSON schema ensures that the payload contains only the expected fields.

Additionally an APIM can validate authentication and authorisation by scope.  This ensures that the client has the correct credentials before the API processes the request.

Tyk approach

Payload validation can be implemented in various ways with the Tyk APIM.

  1. JSON schema validation to ensure the payload meets the defined schema, and rejects payloads that do not.
  2. Body transformation allows using string template syntax, which is a powerful tool for generating the desired output from the input.
  3. Custom plugins for more complex cases or logic not satisfied by the first 2, users can write custom plugins in a variety of languages, either directly or through gRPC calls, to implement their requirements.
  4. Request method transformation while not directly a Mass Assignment prevention, it is a feature that can help ensure that APIs are called with the correct methods.

In addition to the technical solutions mentioned above, Tyk also recommends considering splitting Admin APIs from client facing APIs. By having the admin usage of APIs separate from client facing APIs then different policies, payload validation methods, authentication and authorisation checks in the APIM can be separated and managed under different governance models providing a clear split between the roles.


You can also check out our continuously updated OWASP resource hub for a collection of guides, docs and videos to guide you through essential OWASP practices.