Règle
Se prémunir contre lenteur régulières lentes.
Les régulières avec des imbriquées quantificateurs imbriqués ou 
ambiguës ambiguës peuvent causer catastrophique 
retour en arrière et des performance de performance.
Langues prises en charge : 45+

Introduction

Les expressions régulières peuvent bloquer votre application pendant quelques secondes ou quelques minutes si elles sont correctement saisies. Un retour en arrière catastrophique se produit lorsque les moteurs d'expressions régulières explorent des chemins qui augmentent de façon exponentielle lorsqu'ils tentent de faire correspondre un motif. Une expression régulière comme (a+)+b prend des microsecondes pour correspondre à une entrée valide, mais peut prendre des heures pour rejeter une chaîne de a sans b à la fin. Les attaquants exploitent cette situation par le biais d'attaques de déni de service par expression régulière (ReDoS), en envoyant une entrée fabriquée qui fait en sorte que votre moteur regex consomme 100 % de l'unité centrale jusqu'à ce que les délais de requête soient dépassés ou que le processus s'arrête.

Pourquoi c'est important

Implications en matière de sécurité (attaques ReDoS) : Un attaquant peut paralyser votre application avec une seule demande contenant des données élaborées. La validation des courriels et les modèles d'analyse d'URL sont des cibles courantes. Contrairement aux attaques DoS traditionnelles qui nécessitent de la bande passante, ReDoS n'a besoin que de minuscules charges utiles.

Dégradation des performances : Une saisie normale de l'utilisateur peut déclencher un retour en arrière catastrophique, faisant passer les temps de réponse de quelques millisecondes à quelques secondes. Il en résulte une latence imprévisible, difficile à déboguer car elle ne se manifeste qu'avec des schémas d'entrée spécifiques.

Incidents de production : Les expressions rationnelles vulnérables bloquent la boucle d'événements dans Node.js ou consomment les ressources du pool de threads. Au fur et à mesure que les demandes s'accumulent, la mémoire augmente et le système ne répond plus. Dans les microservices, une regex vulnérable entraîne des défaillances en cascade dans les services dépendants.

Difficulté de détection : Les modèles qui fonctionnent bien dans les tests avec des entrées courtes deviennent exponentiellement lents avec des entrées plus longues. La vulnérabilité passe souvent inaperçue jusqu'à la production, ce qui nécessite un déploiement d'urgence lors d'un incident actif.

Exemples de code

❌ Non conforme :

function validateEmail(email) {
    const regex = /^([a-zA-Z0-9_\-\.]+)+@([a-zA-Z0-9_\-\.]+)+\.([a-zA-Z]{2,5})$/;
    return regex.test(email);
}

function extractURLs(text) {
    const regex = /(https?:\/\/)?([\w\-])+\.(\w+)+([\w\-\.,@?^=%&:/~\+#]*)+/g;
    return text.match(regex);
}

Pourquoi ce n'est pas sûr : Les quantificateurs imbriqués ([a-zA-Z0-9_\\-\\.]+)+ créent un retour en arrière exponentiel. Pour un courriel comme aaaaaaaaaaaaaaaaaaaaaaaaa !Le moteur d'expressions rationnelles essaie d'innombrables combinaisons avant d'échouer. L'expression rationnelle de l'URL comporte plusieurs quantificateurs imbriqués qui aggravent le problème, ce qui la rend trivialement exploitable avec des entrées telles que de longues chaînes de caractères valides sans la structure attendue.

✅ Conforme :

function validateEmail(email) {
    const regex = /^[a-zA-Z0-9_\-\.]+@[a-zA-Z0-9_\-\.]+\.[a-zA-Z]{2,5}$/;
    return regex.test(email);
}

function extractURLs(text) {
    const regex = /https?:\/\/[\w\-]+\.[\w\-]+(?:[\w\-\.,@?^=%&:/~\+#]*)?/g;
    return text.match(regex);
}

Pourquoi c'est sûr : La suppression des quantificateurs imbriqués permet d'éviter les retours en arrière catastrophiques. Les quantificateurs simples tels que [a-zA-Z0-9_\-\.]+ s'exécutent en temps linéaire. Le modèle d'URL utilise des groupes non capturants avec un suffixe facultatif (? :...) ? au lieu d'une répétition imbriquée, ce qui garantit des performances prévisibles quelle que soit la longueur ou le contenu de l'entrée.

Conclusion

Les performances des expressions régulières sont un problème de sécurité, et non une simple optimisation. Examinez tous les modèles d'expressions régulières pour détecter les quantificateurs imbriqués, les classes de caractères qui se chevauchent dans les groupes de répétition et les alternatives ambiguës. Testez les modèles de regex avec des entrées pathologiques (longues chaînes de caractères valides suivies de terminaisons non valides) afin d'identifier les retours en arrière catastrophiques avant le déploiement. Dans la mesure du possible, remplacer les expressions rationnelles complexes par des fonctions d'analyse de chaînes de caractères dont les performances sont prévisibles.