Edit in GitHubLog an issue

Mass assignment

Mass assignment is a type of attack in which a client inserts or updates data that either should not be available to the user, or should require additional authorization.

For example, you have an endpoint or a page where users can edit their personal information. The user table in your database contains the following columns:

  • id
  • first_name
  • last_name
  • email
  • password_hash
  • is_admin

You want users to be able to edit their first and last names only on a page or through the endpoint, but inside the controller/service contract, you have code that looks something like this:

Copied to your clipboard
1$user = $repository->findById($authContext->getUserId());
3$dbConnection->updateTable('users', $user->getData(), ['id' => $user->getId()]);

When a client only provides first_name and last_name properties, this code will perform as expected, but it is vulnerable to mass assignment attacks.

The first vulnerability is through the id property. Users are meant to be able to edit only their own data, but here an attacker can set an id in their request. The$user object's ID will be overwritten, so when you call $dbConnection->updateTable(), instead of having the ID from $authContext, you will have an arbitrary ID from the HTTP request. This will allow an attacker to override data of any user in your system!

The second possible vulnerability is through the is_admin property. Clearly, the property was meant to be writable only by other admins, and maybe even by using another page/endpoint. Using the code above, an attacker can set "is_admin": true inside a request and gain admin access when you save the user record.

Given the users table structure, and depending on your application's logic, email can also be a vulnerable property. An attacker might be able to change their email to any other address without confirming it first.

Mass assignment and the Commerce framework#

If you are not careful and, especially, if you use the legacy approach described below, it is easy to make yourself vulnerable to mass assignment.

Legacy approach#

The legacy approach of exposing data to be writable by users means having a controller that uses Magento\Framework\Model\AbstractModel and sets request data directly, instead of doing so with a DTO and a service contract.

Copied to your clipboard
1class Save extends \Magento\Backend\App\Action implements HttpPostActionInterface
3 ...
6 public function execute()
7 {
8 $data = $this->getRequest()->getPostValue();
9 /** @var MyModel $model */
10 $model = $this->modelFactory->create()
11 ->load($this->getRequest()->getParam('id'));
12 $model->setData($data);
13 $model->save();
15 return $this->generateRedirect();
16 }

As you can see, this example is similar to the generic example with users before. We take all data from the request, thus allowing the client to override ANY property that the model (table) has and then store it.

Newer approach#

A more recent practice is to have service contracts and DTOs that are directly exposed as REST APIs, used inside related controllers and GraphQL resolvers.

Copied to your clipboard
1<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Api/etc/extension_attributes.xsd">
2 <extension_attributes for="\MyStore\MyModule\Api\Data\User">
3 <attribute code="is_admin" type="boolean" />
4 </extension_attributes>
7<routes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
8 xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Webapi:etc/webapi.xsd">
9 <route url="/V1/users" method="PUT">
10 <service class="MyStore\MyModule\Api\UserManagerInterface" method="save"/>
11 <resources>
12 <resource ref="self"/>
13 </resources>
14 </route>
Copied to your clipboard
1interface UserInterface extends ExtensibleDataInterface
3 public function getId(): int;
4 public function getFirstName(): string;
5 public function getLastName(): string;
6 public function getEmail(): string;
7 public function getPasswordHash(): string;
8 public function getExtensionAttributes(): \MyStore\MyModule\Api\Data\UserExtensionInterface;
9 public function setExtensionAttributes(\MyStore\MyModule\Api\Data\UserExtensionInterface $extensionAttributes): void;
12class UserModel extends AbstractModel implements UserInterface
14 ...
17interface UserManagerInterface
19 public function save(\MyStore\MyModule\Api\Data\UserInterface $user): \MyStore\MyModule\Api\Data\UserInterface;
22class Save extends \Magento\Framework\App\Action\Action implements HttpPostActionInterface
24 ...
26 /**
27 * @var DataObjectHelper
28 */
29 private $dataObjectHelper;
31 /**
32 * @var UserManagerInterface
33 */
34 private $manager;
36 ...
38 public function execute()
39 {
40 $data = $this->getRequest()->getPostValue();
41 /** @var UserInterface|UserModel $user */
42 $user = $this->repo->findById($this->userContext->getUserId());
43 //hydration
44 $this->dataObjectHelper->populateWithArray($user, $data, UserInterface::class);
46 //Saving
47 $this->manager->save($user);
49 return $this->generateRedirect();
50 }

In this example, UserInterface is the DTO for the operation, and UserManagerInterface is the service contract. From the XML snippet above, you can see that the isAdmin property is added to the UserInterface DTO as an extension attribute. You can also see that UserManagerInterface::save() can be invoked directly by accessing the REST endpoint PUT /V1/users. We also use the service contract inside the Save controller, which handles a page that enables a user to edit personal info.

This approach is better because we do not accept all data coming from client request blindly, but rather only those properties strictly defined inside UserInterface with getters. For REST APIs, this is ensured by the application framework automatically, and inside the controller, we hydrate the user object retrieved from the DB with DataObjectHelper.

However, because our DTO is also implemented by a class that extends AbstractModel, it's a de facto active record of the users table. As a result, we still have the issue where we exposed the id, is_admin, and email properties. The same vulnerabilities persist.


The vulnerability can be fixed relatively easily by having a strict list of properties accepted by your controllers/service contracts that do not necessarily correlate with the storage schema. This can be achieved by using operation-specific DTOs instead of persistence-layer DTOs.


Copied to your clipboard
1<routes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2 xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Webapi:etc/webapi.xsd">
3 <route url="/V1/users" method="PUT">
4 <service class="MyStore\MyModule\Api\UserManagerInterface" method="update"/>
5 <resources>
6 <resource ref="self"/>
7 </resources>
8 <data>
9 <!-- Enforcing UpdatedUserDataInterface::getId() to always equal to current user's ID -->
10 <parameter name="user.id" force="true">%user_id%</parameter>
11 </data>
12 </route>
Copied to your clipboard
1interface UpdatedUserDataInterface extends ExtensibleDataInterface
3 //This property will be enforced by controller/webapi
4 public function getId(): int;
5 //Only having properties that you wish to be writable by users themselves
6 public function getFirstName(): string;
7 public function getLastName(): string;
8 public function getExtensionAttributes(): \MyStore\MyModule\Api\Data\UpdatedUserDataExtensionInterface;
9 public function setExtensionAttributes(\MyStore\MyModule\Api\Data\UpdatedUserDataExtensionInterface $extensionAttributes): void;
12//Read-only DTO
13interface UserInfoInterface extends ExtensibleDataInterface
15 public function getId(): int;
16 public function getFirstName(): string;
17 public function getLastName(): string;
18 public function getEmail(): string;
19 public function getExtensionAttributes(): \MyStore\MyModule\Api\Data\UserInfoExtensionInterface;
20 public function setExtensionAttributes(\MyStore\MyModule\Api\Data\UserInfoExtensionInterface $extensionAttributes): void;
23//Notice the implementation extending simple DataObject instead of the model.
24class UpdatedUserData extends DataObject implements UpdatedUserDataInterface
26 ...
29interface UserManagerInterface
31 public function update(\MyStore\MyModule\Api\Data\UpdatedUserDataInterface $user): \MyStore\MyModule\Api\Data\UserInfoInterface;
34class Save extends \Magento\Framework\App\Action\Action implements HttpPostActionInterface
36 ...
38 /**
39 * @var DataObjectHelper
40 */
41 private $dataObjectHelper;
43 /**
44 * @var UserManagerInterface
45 */
46 private $manager;
48 ...
50 public function execute()
51 {
52 $data = $this->getRequest()->getPostValue();
53 //Enforcing user ID.
54 $data['id'] = $this->userContext->getUserId();
55 $updatedData = new UpdatedUserData();
56 //hydration
57 $this->dataObjectHelper->populateWithArray($updatedData, $data, UpdatedUserDataInterface::class);
59 //Saving
60 $this->manager->update($updatedData);
62 return $this->generateRedirect();
63 }

You can see that UpdatedUserDataInterface only contains properties that we want users to be able to update. It is not an AbstractModel, but rather a simple data container (DataObject), so we won't have to add any new properties, even if we add new columns to the table. We'll only update UpdatedUserDataInterface explicitly when we want to make a property writeable by clients.

However, we still have getId as a part of the DTO in order to identify which user to update. That means that we need to ensure that the property will contain the value we want, and not a user defined value. For REST APIs, we achieve this with the parameter tag, which will find a registered ParamOverrider and use it to override whatever the client has provided. In the controller, we do this by explicitly setting id as current user ID.

Note that UserManagerInterface returns UserInfoInterface, which is another DTO, and not an AbstractModel. It serves a similar purpose: to expose only the properties to clients that we want them to see. This example does not contain getPasswordHash(), for instance.


In the example above, we skipped the isAdmin() user property. We don't want users to access this property themselves, but we do want this property to be writeable by other admin users.

The best solution here would be to have a separate service, controller, and DTOs meant for admin users that would expose more properties like isAdmin() with the endpoints/pages requiring authorization to related resources.

For example:

Copied to your clipboard
1<routes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2 xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Webapi:etc/webapi.xsd">
3 <route url="/V1/admin/users" method="PUT">
4 <service class="MyStore\MyModule\Api\AdminUserManagerInterface" method="save"/>
5 <resources>
6 <resource ref="Magento_User::manage"/>
7 </resources>
8 </route>
Copied to your clipboard
1interface UserFullDataInterface extends ExtensibleDataInterface
3 //Properties we wish admins have access to
4 public function getId(): int;
5 public function getFirstName(): string;
6 public function getLastName(): string;
7 public function isAdmin(): bool;
8 public function isActive(): bool;
9 public function getExtensionAttributes(): \MyStore\MyModule\Api\Data\UserFullDataExtensionInterface;
10 public function setExtensionAttributes(\MyStore\MyModule\Api\Data\UserFullDataExtensionInterface $extensionAttributes): void;
14//Read-only DTO
15interface FullUserInfoInterface extends ExtensibleDataInterface
17 public function getId(): int;
18 public function getFirstName(): string;
19 public function getLastName(): string;
20 public function getEmail(): string;
21 public function isAdmin(): boolean;
22 public function isActive(): string;
23 public function getExtensionAttributes(): \MyStore\MyModule\Api\Data\FullUserInfoExtensionInterface;
24 public function setExtensionAttributes(\MyStore\MyModule\Api\Data\FullUserInfoExtensionInterface $extensionAttributes): void;
27//Notice the implementation extending simple DataObject instead of the model.
28class UserFullData extends DataObject implements UserFullDataInterface
30 ...
33interface AdminUserManagerInterface
35 public function save(\MyStore\MyModule\Api\Data\UserFullDataInterface $user): \MyStore\MyModule\Api\Data\FullUserInfoInterface;
38class Save extends \Magento\Backend\App\Action implements HttpPostActionInterface
40 ...
42 const ADMIN_RESOURCE = 'Magento_User::manage';
44 /**
45 * @var DataObjectHelper
46 */
47 private $dataObjectHelper;
49 /**
50 * @var AdminUserManagerInterface
51 */
52 private $manager;
54 ...
56 public function execute()
57 {
58 $data = $this->getRequest()->getPostValue();
59 $userData = new UserFullData();
60 //hydration
61 $this->dataObjectHelper->populateWithArray($userData, $data, UserFullDataInterface::class);
63 //Saving
64 $this->manager->save($userData);
66 return $this->generateRedirect();
67 }

Notice how both the endpoint and the controller now require authorization for Magento_User::manage. In an earlier example, we had isAdmin() property added to UserInterface as an extension attribute. If we have the same DTOs for operations that require additional authorization and those that do not, we risk other extensions exposing vulnerable data. With this approach, another extension can decide to only add certain properties to DTOs available only to admin users by providing extension attributes for UserFullDataInterface only.


For GraphQL APIs, the application does not rely on interfaces to generate schema. Instead, we have explicit GraphQL schemas, and there is no risk of exposing fields accidentally when you update data storage schema. However, if for some reason some fields do require additional authorization, you would still need to verify it explicitly.

Was this helpful?
  • Privacy
  • Terms of Use
  • Do not sell my personal information
  • AdChoices
Copyright © 2022 Adobe. All rights reserved.