Glossaire
Race Condition (condition de concurrence)
Vulnérabilité qui survient lorsque le résultat d'une opération dépend de l'ordre d'exécution de processus concurrents. Les race conditions permettent de contourner les limites de solde, dupliquer des transactions ou bypasser des vérifications d'autorisation. Elles sont particulièrement critiques dans les systèmes de paiement et les API fintech.
Comment une race condition devient une faille
Une race condition survient quand deux traitements concurrents accèdent à la même ressource sans synchronisation, et que le résultat dépend de l'ordre d'exécution. En sécurité applicative, le schéma le plus courant est le TOCTOU (time-of-check to time-of-use) : l'application vérifie une condition (solde suffisant, code promo non utilisé, quota disponible) puis agit, mais entre les deux, une requête parallèle a changé l'état. En envoyant des dizaines de requêtes simultanées, un attaquant fait passer plusieurs traitements entre la vérification et l'action.
Exemples dans un SaaS RH ou paie
Les cas concrets ne manquent pas : valider deux fois le même solde de congés en soumettant les demandes simultanément, dépasser un quota de licences ou d'utilisateurs facturés, réutiliser un jeton d'invitation ou de réinitialisation de mot de passe à usage unique, générer deux virements pour un même remboursement de frais. Les architectures modernes aggravent le risque : plusieurs instances serveur derrière un load balancer multiplient les fenêtres de concurrence si la synchronisation repose sur la mémoire locale.
Détection et correction
En audit, nous testons les opérations sensibles avec des rafales de requêtes parallèles pour révéler les fenêtres de concurrence, en environnement de test et sans impact sur la production. Côté correction : contraintes d'unicité et transactions avec verrouillage en base de données (SELECT FOR UPDATE, contraintes UNIQUE), opérations atomiques, jetons consommés de manière transactionnelle, et idempotence des endpoints critiques.
Questions fréquentes
Les race conditions sont-elles vraiment exploitables à distance ?
Oui. Les techniques modernes (requêtes HTTP/2 multiplexées, envoi en « single-packet attack ») permettent de faire arriver des dizaines de requêtes dans la même milliseconde, rendant les fenêtres de concurrence très exploitables même sur des applications distantes.
Comment corriger une race condition sur un solde ou un quota ?
Déplacer le contrôle au niveau de la base de données : transaction avec verrouillage de la ligne concernée, contrainte CHECK ou UNIQUE, ou opération atomique (UPDATE ... WHERE solde >= montant). La vérification applicative seule, même dupliquée, ne ferme pas la fenêtre.
Un test unitaire peut-il détecter ces failles ?
Difficilement : les tests unitaires s'exécutent séquentiellement. Il faut des tests de charge concurrents ciblés sur les opérations à état (paiements, quotas, jetons à usage unique) ou un audit qui reproduit les conditions réelles d'exploitation.