La faille MOVEit : 60 millions de victimes via une API mal sécurisée

Le 31 mai 2023, un groupe de cybercriminels (Cl0p) exploite une vulnérabilité zero-day dans MOVEit Transfer, un logiciel de transfert de fichiers massivement utilisé par les entreprises et administrations. La faille : une injection SQL dans l'API REST du produit, permettant d'accéder à toute la base de données sans authentification. En quelques jours, les données de plus de 60 millions de personnes sont exfiltrées — incluant des numéros de sécurité sociale, des dossiers médicaux et des informations bancaires provenant de centaines d'organisations dans 40 pays.

Ce n'est pas un cas isolé. Akamai, dans son rapport "State of the Internet" 2023, révèle que les APIs représentent désormais 83% du trafic web total — et sont devenues la cible privilégiée des attaquants. Entre 2022 et 2023, les attaques ciblant les APIs ont augmenté de 137%.

« Une API non sécurisée n'est pas une interface de programmation — c'est une porte dérobée ouverte sur vos données. »

Les 5 vecteurs d'attaque les plus courants sur les APIs REST

1. Broken Object Level Authorization (BOLA)

L'attaque la plus courante selon l'OWASP API Top 10. Un utilisateur authentifié modifie l'identifiant d'un objet dans l'URL : /api/dossiers/1234 devient /api/dossiers/1235. Si l'API ne vérifie pas que l'utilisateur a le droit d'accéder à cet objet spécifique (pas seulement qu'il est authentifié), les données d'un autre client sont exposées.

Dans RecruteX, chaque endpoint vérifie systématiquement que l'objet demandé appartient au tenant de l'utilisateur authentifié — pas seulement que le token JWT est valide.

2. Injection SQL dans les paramètres d'API

C'est exactement la vulnérabilité exploitée dans MOVEit. Un paramètre API (?search=texte) construit dans une requête SQL par concaténation devient un vecteur d'injection. La parade : requêtes préparées PDO sur 100% des accès base de données, sans exception.

3. Authentification cassée ou contournable

Les tokens JWT mal validés sont une source fréquente de vulnérabilités. Un token mal signé, un algorithme none accepté par le serveur, une expiration non vérifiée — ces failles permettent de forger des tokens valides et d'usurper des identités.

4. Absence de rate limiting

Une API sans rate limiting est vulnérable à plusieurs types d'attaques : brute force sur les endpoints d'authentification, énumération d'identifiants, scraping massif de données. Le coût d'une attaque sans rate limiting peut aussi être financier si l'API s'appuie sur des services tiers facturés à l'appel.

5. CORS trop permissif

Access-Control-Allow-Origin: * est l'équivalent d'une API publique pour les navigateurs web — n'importe quel site peut y envoyer des requêtes authentifiées au nom d'un utilisateur connecté. Le CORS doit être restreint aux domaines autorisés explicitement.

Le protocole de sécurité de l'API RecruteX

RecruteX gère plus de 50 tenants actifs avec des données sensibles (CV, coordonnées de candidats, informations de recrutement). Voici les couches de sécurité en place :

Authentification JWT avec rotation de tokens

Chaque requête à l'API est authentifiée via un JWT signé en HS256 avec une clé secrète de 256 bits rotée tous les 30 jours. Le token encode le user_id, le tenant_id, et une expiration de 15 minutes. Un refresh token (HTTPOnly cookie, durée 7 jours) permet le renouvellement silencieux. Les tokens révoqués sont stockés en base jusqu'à leur expiration naturelle.

Validation systématique des droits au niveau objet

Chaque endpoint suit le pattern : 1) valider le JWT, 2) extraire le tenant_id, 3) vérifier que l'objet demandé appartient à ce tenant, 4) vérifier le rôle de l'utilisateur dans ce tenant. Un utilisateur valide du tenant A ne peut jamais accéder aux données du tenant B — même s'il devine un identifiant valide.

Rate limiting par IP et par token

Les endpoints d'authentification acceptent maximum 5 tentatives par IP par tranche de 5 minutes. Les endpoints d'API acceptent maximum 100 requêtes par minute par token authentifié. Les dépassements retournent HTTP 429 avec un header Retry-After. Les IPs bloquées sont enregistrées pour analyse.

CORS restreint aux domaines autorisés

La liste des origines autorisées est stockée en base de données et vérifiée à chaque requête cross-origin. Aucun wildcard. Les requêtes d'origines non autorisées reçoivent une réponse 403 avant tout traitement applicatif.

Logging et alerting

Chaque tentative d'authentification échouée, chaque accès refusé pour raison d'autorisation et chaque dépassement de rate limit est loggé avec IP, user agent, timestamp et payload tronqué. Un seuil de 10 erreurs d'autorisation en 5 minutes déclenche une alerte automatique.

Checklist sécurité API : 8 points avant de mettre en production

  1. Toutes les requêtes SQL utilisent-elles des requêtes préparées (zéro concaténation) ?
  2. Chaque objet retourné est-il vérifié comme appartenant au tenant/utilisateur authentifié ?
  3. Les tokens JWT sont-ils validés en signature ET en expiration ET en révocation ?
  4. Les endpoints sensibles ont-ils un rate limiting actif ?
  5. Le CORS est-il restreint à une liste blanche de domaines ?
  6. Les erreurs retournent-elles des messages génériques (sans détails internes) ?
  7. Les inputs sont-ils validés en type, format et longueur avant traitement ?
  8. Les accès API sont-ils loggés avec possibilité d'audit forensique ?

Vous développez ou maintenez une API qui gère des données sensibles ? Demandez un audit de sécurité API → — nous testons vos endpoints et vous livrons un rapport de vulnérabilités avec recommandations priorisées.