With Spring, when a request mapping method is configured to accept bean objects as arguments, the framework will automatically bind HTTP parameters to those objects' properties. If the targeted beans are also persistent entities, the framework will also store those properties in the storage backend, usually the application’s database.

## Why is this an issue?

By accepting persistent entities as method arguments, the application allows clients to manipulate the object’s properties directly.

### What is the potential impact?

Attackers could forge malicious HTTP requests that will alter unexpected properties of persistent objects. This can lead to unauthorized modifications of the entity’s state. This is known as a mass assignment attack.

Depending on the affected objects and properties, the consequences can vary.

#### Privilege escalation

If the affected object is used to store the client’s identity or permissions, the attacker could alter it to change their entitlement on the application. This can lead to horizontal or vertical privilege escalation.

#### Security checks bypass

Because persistent objects are modified directly without prior logic, attackers could exploit this issue to bypass security measures otherwise enforced by the application. For example, an attacker might be able to change their e-mail address to an invalid one by directly setting it without going through the application’s email validation process.

The same could also apply to passwords that attackers could change without complexity validation or knowledge of their current value.

## How to fix it in Java EE

### Code examples

The following code is vulnerable to a mass assignment attack because it allows modifying the `User` persistent entities thanks to maliciously forged `Wish` object properties.

#### Noncompliant code example

    import javax.persistence.Entity;

    @Entity
    public class Wish {
      Long productId;
      Long quantity;
      Client client;
    }

    @Entity
    public class Client {
      String clientId;
      String name;
      String password;
    }

    import org.springframework.stereotype.Controller;
    import org.springframework.web.bind.annotation.RequestMapping;

    @Controller
    public class PurchaseOrderController {

      @RequestMapping(path = "/saveForLater", method = RequestMethod.POST)
      public String saveForLater(Wish wish) { // Noncompliant
        session.save(wish);
      }
    }

#### Compliant solution

    public class WishDTO {
      Long productId;
      Long quantity;
      Long clientId;
    }

    import org.springframework.stereotype.Controller;
    import org.springframework.web.bind.annotation.RequestMapping;

    @Controller
    public class PurchaseOrderController {

      @RequestMapping(path = "/saveForLater", method = RequestMethod.POST)
      public String saveForLater(WishDTO wish) {
        Wish persistentWish = new Wish();
        persistentWish.productId = wish.productId
        persistentWish.quantity = wish.quantity
        persistentWish.client = getClientById(with.clientId)
        session.save(persistentWish);
      }
    }

### How does this work?

The compliant code implements a Data Transfer Object (DTO) layer. Instead of accepting a persistent `Wish` entity as a parameter, the vulnerable method accepts a `WishDTO` object with a safe, minimal set of properties. It then instantiates a persistent entity and initializes it based on the DTO properties' values. The resulting object can safely be persisted in the database.

## Resources

### Documentation

- OWASP - Mass Assignment Cheat Sheet

### Standards

- OWASP - Top 10 2021 - Category A8 - Software and Data Integrity Failures
- OWASP - Top 10 2017 - Category A5 - Broken Access Control
- CWE - CWE-915 - Improperly Controlled Modification of Dynamically-Determined Object Attributes

### Articles & blog posts

OWASP O2 Platform Blog - Two Security Vulnerabilities in the Spring Framework’s MVC