Preventing Mass Assignment Vulnerabilities

1. What Is Mass Assignment?

Mass assignment is a flaw where incoming request data gets mapped automatically and unfiltered onto the properties of an entity or model object. Frameworks often offer this automation to cut boilerplate: a JSON body is translated directly into a PHP object or array update, without assigning every field by hand.

The problem appears the moment an entity has more fields than a client should ever be allowed to set. If a User entity has an isAdmin or role field alongside name and email, an attacker can simply include that field in the request. If it gets bound automatically, the attacker has granted themselves admin rights without needing anything resembling a classic exploit.

2. How a Mass Assignment Attack Plays Out

The flow is disarmingly simple: an attacker signs up for a regular account and observes which fields get accepted when updating their own profile. Often a glance at frontend source code, API documentation, or public entity classes from an open source project is enough to guess internal field names like isAdmin, role, balance, or verified.

The example below shows a Symfony controller that updates profile data. The vulnerable version binds the entire request directly onto the entity. The fixed version uses a DTO with a fixed list of allowed fields.

<?php

declare(strict_types=1);

namespace App\Controller\Api;

use App\Dto\UpdateProfileRequest;
use App\Entity\User;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Annotation\Route;
use Symfony\Component\Serializer\SerializerInterface;

final class ProfileApiController extends AbstractController
{
    public function __construct(
        private readonly EntityManagerInterface $entityManager,
        private readonly SerializerInterface $serializer,
    ) {
    }

    // Vulnerable: request JSON is mapped directly onto the entity
    #[Route('/api/profile', methods: ['PATCH'])]
    public function updateVulnerable(Request $request): JsonResponse
    {
        $user = $this->getUser();
        $data = json_decode($request->getContent(), true);

        // Every field from the request lands on the entity unchecked,
        // including isAdmin or role if the client sends them.
        foreach ($data as $property => $value) {
            $setter = 'set' . ucfirst($property);
            if (method_exists($user, $setter)) {
                $user->$setter($value);
            }
        }

        $this->entityManager->flush();

        return $this->json(['status' => 'updated']);
    }

    // Fixed: DTO with a fixed allowlist of writable fields
    #[Route('/api/profile', methods: ['PATCH'])]
    public function updateSecured(Request $request): JsonResponse
    {
        /** @var UpdateProfileRequest $dto */
        $dto = $this->serializer->deserialize(
            $request->getContent(),
            UpdateProfileRequest::class,
            'json'
        );

        $user = $this->getUser();
        // Only fields explicitly declared on the DTO can ever arrive here
        $user->setDisplayName($dto->displayName);
        $user->setEmail($dto->email);

        $this->entityManager->flush();

        return $this->json(['status' => 'updated']);
    }
}

3. Allowlist Instead of Blocklist

A blocklist approach tries to explicitly exclude dangerous fields, for example by stripping isAdmin out of the array before mapping. This is fragile, because every new sensitive field added to the entity later has to be actively added to the blocklist too. Miss that step once, and the gap is back immediately, often without anyone noticing during review.

An allowlist approach flips the logic: it explicitly defines which fields a client may set, and everything else is locked out by default. New fields are automatically safe until someone deliberately adds them to the allowlist. DTOs, Symfony forms with an explicit field list, and serializer groups all implement exactly this principle at the technical level.

4. Real World Hotspots

Beyond classic user entities with role fields, orders with price or status fields are just as exposed: a client that can send a price field during checkout that gets applied directly could effectively set their own price. Status fields like isPaid or isApproved are equally sensitive, since they should only ever be set by server side business logic.

Doctrine forms with CSRF protection are not automatically safe either, if the underlying FormType binds every entity field without thought instead of deliberately declaring only the fields a client should be allowed to set. A FormType is a good starting point for an allowlist, but it needs the same ongoing care as a DTO.

5. DTOs Instead of Direct Entity Binding in Symfony

In Symfony, DTOs pair nicely with the Serializer component and property level validation through the Symfony Validator. A DTO contains only the fields genuinely needed for a specific use case, with its own validation rules independent of the constraints defined on the entity.

The mapping step from DTO to entity then happens explicitly in the controller or in a dedicated mapper service, with clearly named setters for each allowed field. This extra step looks like more code at first glance, but it shrinks the attack surface significantly and makes the allowed fields obvious to any developer at a glance.

6. Serializer Groups as an Alternative

Teams that do not want to build a dedicated DTO for every endpoint can work with Symfony serializer groups instead. Entity properties get annotated with groups such as profile:write, and only fields in that group are considered during deserialization. Sensitive fields like roles deliberately get no write group at all.

This approach is faster to set up than full DTOs, but carries the risk that a new field gets accidentally assigned to a group that is too permissive. DTOs remain the more robust choice for security critical entities like User or Payment.

7. Testing for Mass Assignment Deliberately

A simple but effective test sends a known sensitive field like isAdmin or role with a different value alongside the expected fields on every write endpoint. After the request, it checks whether the sensitive field's value actually changed. If it stayed the same, the allowlist is working as intended.

This test is easy to automate and worth making a mandatory part of the CI pipeline for every new PATCH or PUT endpoint, similar to the two-account test used against BOLA.

8. Common Mistakes in Implementation

A common mistake is consistently using DTOs or FormTypes for new endpoints while leaving older, existing endpoints on direct entity binding because migrating them feels like too much effort. In practice, exactly this kind of legacy code is the most frequent source of mass assignment incidents.

Another mistake is assuming admin areas are inherently safer than public APIs and skipping the allowlist there. Admin interfaces are reached through the same HTTP mechanisms as public APIs and are just as vulnerable once an attacker gets hold of a compromised or over-privileged account.

9. Best Practices and Checklist

Every write endpoint should work with an explicit allowlist, whether through a DTO, a FormType with defined fields, or serializer groups. Sensitive fields like roles, prices, or status values should only ever be set through dedicated, server side endpoints or internal services, never through the same endpoint as routine profile data.

It also helps to have an automated test per endpoint that attempts to overwrite a known sensitive field, plus a code review standard that rejects direct entity binding from request data on principle.

10. Summary

11. FAQ: Mass Assignment