Mass Assignment

Qu'est-ce que le Mass Assignment ?#

Le mass assignment (CWE-915 : Modification incorrectement contrôlée des attributs d'objet déterminés dynamiquement) est une vulnérabilité où un framework web mappe automatiquement les paramètres d'une requête HTTP sur les propriétés d'un objet ou modèle ORM côté serveur. Lorsque le framework n'applique pas de liste blanche explicite des champs accessibles en écriture, un attaquant peut injecter des attributs privilégiés — role, is_admin, subscription_tier, credit_balance — jamais destinés à être contrôlés par l'utilisateur.

L'OWASP API Security Top 10 2023 subsume le mass assignment sous API3:2023 BOPLA (Broken Object Property Level Authorization), couvrant à la fois la direction écriture (mass assignment) et la direction lecture (exposition excessive de données). Selon l'OWASP, cela affecte plus de 30 % des APIs testées en 2025.

Le mass assignment est architecturalement distinct de l'IDOR (Broken Object Level Authorization / BOLA). L'IDOR contrôle les objets auxquels vous pouvez accéder. Le mass assignment contrôle les champs que vous pouvez écrire sur les objets auxquels vous accédez légitimement. Les deux sont fréquemment chaînés : une faiblesse BOLA donne accès à l'objet cible, et une faiblesse BOPLA permet de modifier ses champs privilégiés.

Mécanisme#

La vulnérabilité a une cause racine unique : l'application passe des données contrôlées par l'utilisateur directement à un appel de liaison ORM sans filtrer préalablement les clés autorisées.

Le flux d'attaque :

1. L'attaquant identifie un endpoint acceptant un corps JSON pour les mises à jour : PATCH /users/me, PUT /accounts/:id, POST /register.
2. Une requête GET légitime révèle la forme de la réponse — y compris les champs comme role, is_admin qui semblent en lecture seule.
3. L'attaquant renvoie la requête de mise à jour avec ces champs privilégiés ajoutés au corps.
4. Le framework passe le corps complet analysé à l'ORM sans filtrage.
5. L'ORM écrit chaque champ en base, y compris les champs injectés.
6. Un GET ultérieur (avec un token de session différent) confirme la persistance.

Démonstration minimale :

PATCH /api/v1/users/me HTTP/1.1
Host: cible.example.com
Authorization: Bearer <token_utilisateur>
Content-Type: application/json
 
{
  "email": "attaquant@example.com",
  "role": "admin",
  "is_superuser": true,
  "subscription_tier": "enterprise",
  "credit_balance": 999999
}

HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "id": 42,
  "email": "attaquant@example.com",
  "role": "admin",
  "subscription_tier": "enterprise"
}

Variantes d'attaque#

Exemples réels#

GitHub 2012 — Homakov Mass Assignment Rails En mars 2012, le chercheur en sécurité Egor Homakov a exploité une vulnérabilité de mass assignment sur GitHub.com en production. En postant une clé SSH avec un paramètre owner_id pointant vers l'organisation rails/rails, il a associé sa clé publique à cette organisation sans autorisation. Cet incident a directement conduit à l'introduction de strong_parameters comme fonctionnalité obligatoire dans Rails 4 (2013).

CVE-2024-52034 — Strapi CMS (CVSS 8.1, 2024) Strapi v4.x PATCH /api/users/:id acceptait les champs role, confirmed et blocked dans le corps de la requête sans liste blanche explicite. Les utilisateurs authentifiés pouvaient s'escalader en admin en envoyant {"role": "<id-role-admin>"}. Correction dans Strapi 4.25.x. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.

CVE-2025-32433 — Directus CMS (CVSS 8.8, 2025) Directus exposait la table directus_users via des endpoints CRUD automatiques avec le champ role accessible en écriture. PATCH /users/me avec {"role": "<uuid-role-admin>"} élevait tout utilisateur authentifié en administrateur système. Correction dans Directus 10.13+. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N.

CVE-2024-32887 — NocoDB (CVSS 8.8, 2024) L'endpoint de mise à jour de vue de table NocoDB acceptait les champs role et visibility directement depuis le corps de la requête sans couche DTO. N'importe quel utilisateur authentifié pouvait modifier les permissions au niveau de la table.

Détection#

Test manuel#

1. Identifiez les endpoints de mise à jour : PUT /users/:id, PATCH /users/me, PATCH /profile, POST /register.
2. Effectuez un GET légitime sur l'objet cible et relevez tous les champs de la réponse, y compris role, is_admin, subscription_tier.
3. Envoyez un PATCH avec un corps superensemble contenant les champs privilégiés :

PATCH /api/v1/users/me HTTP/1.1
Content-Type: application/json
Authorization: Bearer <token_utilisateur>
 
{
  "email": "vous@example.com",
  "role": "admin",
  "is_admin": true,
  "is_superuser": true,
  "subscription_tier": "enterprise",
  "mfa_required": false
}

4. Effectuez immédiatement un GET avec un token de session différent. Comparez la réponse à la baseline pré-PATCH.
5. Pour GraphQL, interrogez l'introspection pour les types InputObject correspondant à la cible.

Détection automatisée#

Arjun (v3.x) effectue la découverte de paramètres HTTP en envoyant des requêtes avec des noms de paramètres candidats depuis un dictionnaire et en détectant les différences de réponse.

Burp Suite Pro Param Miner détecte les paramètres non documentés via l'analyse différentielle des réponses. Utilisez-le sur les endpoints PATCH avec un corps JSON.

OpenAPI-fuzzer analyse la spec OpenAPI/Swagger de la cible, identifie les champs marqués readOnly: true et tente automatiquement de les écrire.

BreachVex détecte le mass assignment via plusieurs techniques complémentaires : il envoie une sonde PATCH superensemble avec un large jeu de champs candidats et compare la réponse, confirme la persistance via une session authentifiée distincte, et valide un effet secondaire observable (accès à un endpoint admin ou déblocage de fonctionnalité premium) avant de rapporter un finding.

Prévention#

Listes blanches explicites#

Rails — strong_parameters :

# VULNÉRABLE — permet tous les champs
def user_params
  params.require(:user).permit!
end
 
# SÉCURISÉ — liste blanche explicite
def user_params
  params.require(:user).permit(:email, :first_name, :last_name, :bio)
end
 
# Mode strict — lever une exception sur les champs non autorisés
config.action_controller.action_on_unpermitted_parameters = :raise

Django REST Framework — champs explicites :

# VULNÉRABLE
class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = '__all__'
 
# SÉCURISÉ
class UserSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = ['id', 'email', 'first_name', 'last_name', 'bio']
        read_only_fields = ['id', 'is_staff', 'is_superuser', 'groups']

Express + Mongoose — déstructuration :

// VULNÉRABLE
const user = await User.findByIdAndUpdate(req.user.id, req.body, { new: true });
 
// SÉCURISÉ
const { email, firstName, lastName, bio } = req.body;
const user = await User.findByIdAndUpdate(
  req.user.id,
  { email, firstName, lastName, bio },
  { new: true, runValidators: true }
);

Data Transfer Objects (DTOs)#

Pydantic v2 / FastAPI — extra="forbid" :

# SÉCURISÉ — les champs supplémentaires retournent 422
class UserUpdate(BaseModel):
    model_config = ConfigDict(extra="forbid")
    email: EmailStr | None = None
    first_name: str | None = None
    last_name: str | None = None

NestJS — ValidationPipe avec liste blanche :

app.useGlobalPipes(new ValidationPipe({
  whitelist: true,
  forbidNonWhitelisted: true
}));

Test de régression automatisé#

def test_user_cannot_escalate_role(client, user_token):
    response = client.patch(
        "/api/v1/users/me",
        json={"email": "user@example.com", "role": "admin", "is_superuser": True},
        headers={"Authorization": f"Bearer {user_token}"}
    )
    me = client.get("/api/v1/users/me", headers={"Authorization": f"Bearer {user_token}"})
    assert me.json()["role"] == "user"
    assert me.json().get("is_superuser") is not True

Ressources#

• OWASP API Security Top 10 2023 — API3: BOPLA
• OWASP Mass Assignment Cheat Sheet
• CWE-915 : Modification incorrectement contrôlée des attributs d'objet
• Rails Security Guide — Strong Parameters