Quelle est la faille de sécurité d'API la plus fréquente ?

L'autorisation cassée au niveau des objets, aussi appelée IDOR : un endpoint authentifie l'appelant mais ne vérifie pas que l'objet précis demandé lui appartient. Changer un ID dans l'URL renvoie les données de quelqu'un d'autre. La correction est une vérification de propriété, via une policy, à chaque accès objet.

Qu'est-ce que le BOLA / IDOR ?

Broken Object Level Authorization (IDOR est l'ancien nom, Insecure Direct Object Reference). L'API fait confiance à un identifiant de la requête sans vérifier que l'utilisateur authentifié a le droit d'accéder à cet objet, donc incrémenter ou deviner un ID expose les enregistrements d'autres utilisateurs.

Comment se protéger du mass assignment en Laravel ?

Posez une liste $fillable stricte sur le modèle avec seulement les champs qu'un client peut définir, ou validez et ne récupérez que les clés autorisées via un Form Request. Ne passez jamais l'input brut de la requête à create() ou update(). Des champs comme role, is_admin ou account_id ne devraient jamais être dans $fillable.

Faut-il un WAF pour une API ?

Un WAF aide sur les attaques génériques et le rate limiting en bordure, mais il ne corrige pas les failles d'autorisation, qui sont le risque principal des API. C'est une couche utile, pas un substitut aux vérifications de propriété, à la validation des entrées et à une auth correcte dans l'application.

Comment tester la sécurité de son API ?

Écrivez des feature tests qui affirment l'autorisation : un utilisateur ne peut pas lire ou modifier les objets d'un autre, un utilisateur normal reçoit 403 sur les routes admin, le mass assignment de champs protégés est ignoré. Ajoutez un scan de dépendances et d'analyse statique en CI, et pour tout ce qui est sensible, un test d'intrusion manuel périodique.

← Retour au Blog

Backend

Sécuriser une API Laravel : l'OWASP API Top 10 en pratique

Les API échouent surtout sur l'autorisation, pas sur des exploits exotiques. Voici l'OWASP API Security Top 10 traduit en corrections Laravel concrètes, risque par risque.

2026-09-04·12 min

L'OWASP API Security Top 10 n'est pas la même liste que le Top 10 des applications web. Les API sont consommées par du code, donc les risques classiques d'injection et de XSS comptent moins, et les échecs d'autorisation dominent : un endpoint qui vous authentifie correctement mais ne vérifie pas que l'objet demandé est le vôtre. Voici la liste traduite en corrections Laravel.

1. Autorisation cassée au niveau des objets (BOLA / IDOR)

La faille d'API la plus fréquente et la plus dommageable : GET /orders/42 renvoie la commande 42 à tout utilisateur authentifié, pas seulement à son propriétaire. L'authentification n'est pas l'autorisation. Vérifiez la propriété à chaque accès à un objet, avec une policy, et laissez le framework l'imposer.

php

// OrderPolicy
public function view(User $user, Order $order): bool
{
    return $order->customer_id === $user->id;
}

// Contrôleur
public function show(Order $order)
{
    $this->authorize('view', $order); // 403 si ce n'est pas le propriétaire
    return new OrderResource($order);
}

2. Authentification cassée

Gestion faible des tokens, pas de rate limit sur le login, identifiants dans l'URL. Utilisez Sanctum ou JWT correctement, limitez fort le débit des endpoints d'auth, gardez les tokens hors de la query string, et stockez les tokens navigateur dans des cookies httpOnly. Des access tokens courts plus des refresh tokens tournants limitent le rayon de souffle d'une fuite.

3. Autorisation cassée au niveau des propriétés

Deux directions : le mass assignment laisse un client définir des champs qu'il ne devrait pas (is_admin, account_id), et la sur-exposition renvoie des champs qu'il ne devrait pas voir. Gardez les écritures avec un $fillable strict ou des règles de Form Request, et façonnez chaque réponse via une API Resource qui liste exactement ce qui est public.

4. Consommation de ressources non bornée

Pas de rate limiting, endpoints de liste non bornés, requêtes coûteuses, uploads de fichiers illimités. Appliquez un limiteur de débit nommé par utilisateur et par clé, plafonnez la taille de page, mettez en liste blanche les champs triables et filtrables pour qu'un client ne puisse pas forcer un scan complet, et fixez des limites de taille et de type d'upload.

5. Autorisation cassée au niveau des fonctions

Des actions admin atteignables par des utilisateurs normaux parce que la route est seulement « cachée ». Protégez les endpoints privilégiés avec un gate ou un middleware qui vérifie le rôle ou l'ability, groupez-les sous leur propre middleware, et ne comptez jamais sur le client qui ne connaît pas l'URL.

6. Server-side request forgery (SSRF)

Toute fonctionnalité qui récupère une URL fournie par l'utilisateur (webhooks, imports d'images, aperçus de liens) peut être pointée vers votre réseau interne ou l'endpoint de métadonnées cloud. Validez l'URL, résolvez-la, et rejetez les plages d'IP privées et link-local avant que la requête ne parte. Une allowlist de hosts permis est plus forte qu'une blocklist.

7. Mauvaise configuration de sécurité

APP_DEBUG à on en production qui fait fuir les stack traces et la config, CORS permissif, headers de sécurité manquants, messages d'erreur verbeux. Livrez avec debug à off, verrouillez le CORS sur les origines connues, posez les headers de sécurité standard, et renvoyez la forme problem RFC 9457 sans détail interne.

8. Mauvaise gestion de l'inventaire

De vieilles versions d'API encore en service et non patchées, des endpoints de staging exposés, des routes non documentées. Gardez un inventaire exact, retirez les versions dépréciées selon un calendrier annoncé, et assurez-vous que les environnements hors production ne sont pas atteignables depuis Internet.

Risque, symptôme, correction Laravel

Risque	Comment il se manifeste	Correction Laravel
BOLA / IDOR	Changer un ID dans l'URL renvoie les données d'un autre utilisateur	Policy + authorize() à chaque accès objet
Auth cassée	La force brute marche, tokens dans les URL	Auth rate-limitée, Sanctum/JWT, cookies httpOnly
Auth au niveau des propriétés	Le client pose is_admin, la réponse fait fuir des champs	$fillable strict / Form Request, API Resources
Consommation de ressources	Un client dégrade le service	Limiteur nommé, plafonds de page, filtres en liste blanche
Auth au niveau des fonctions	Un utilisateur normal atteint une route admin	Gate / middleware par ability, routes groupées
SSRF	Une URL utilisateur atteint des services internes	Valider et résoudre l'URL, bloquer les plages privées, allowlist
Mauvaise configuration	Stack traces en prod, CORS ouvert	Debug off, CORS verrouillé, headers de sécurité

FAQ

Quelle est la faille de sécurité d'API la plus fréquente ?: L'autorisation cassée au niveau des objets, aussi appelée IDOR : un endpoint authentifie l'appelant mais ne vérifie pas que l'objet précis demandé lui appartient. Changer un ID dans l'URL renvoie les données de quelqu'un d'autre. La correction est une vérification de propriété, via une policy, à chaque accès objet.
Qu'est-ce que le BOLA / IDOR ?: Broken Object Level Authorization (IDOR est l'ancien nom, Insecure Direct Object Reference). L'API fait confiance à un identifiant de la requête sans vérifier que l'utilisateur authentifié a le droit d'accéder à cet objet, donc incrémenter ou deviner un ID expose les enregistrements d'autres utilisateurs.
Comment se protéger du mass assignment en Laravel ?: Posez une liste $fillable stricte sur le modèle avec seulement les champs qu'un client peut définir, ou validez et ne récupérez que les clés autorisées via un Form Request. Ne passez jamais l'input brut de la requête à create() ou update(). Des champs comme role, is_admin ou account_id ne devraient jamais être dans $fillable.
Faut-il un WAF pour une API ?: Un WAF aide sur les attaques génériques et le rate limiting en bordure, mais il ne corrige pas les failles d'autorisation, qui sont le risque principal des API. C'est une couche utile, pas un substitut aux vérifications de propriété, à la validation des entrées et à une auth correcte dans l'application.
Comment tester la sécurité de son API ?: Écrivez des feature tests qui affirment l'autorisation : un utilisateur ne peut pas lire ou modifier les objets d'un autre, un utilisateur normal reçoit 403 sur les routes admin, le mass assignment de champs protégés est ignoré. Ajoutez un scan de dépendances et d'analyse statique en CI, et pour tout ce qui est sensible, un test d'intrusion manuel périodique.

La sécurité d'une API, c'est surtout de l'autorisation faite de façon cohérente : chaque accès à un objet vérifie la propriété, chaque action privilégiée vérifie l'ability, chaque entrée est validée et chaque réponse est façonnée. Parcourez l'OWASP API Top 10 face à vos endpoints une fois, ajoutez les vérifications manquantes, et couvrez-les de tests pour qu'elles restent.

Besoin d'aide sur ce sujet ? Audit Technique

Découvrir ce service →