Nouvelle catégorie de risque dans le Top 10 de l'OWASP : S'attendre à l'inattendu
Avec la publication par l'OWASP de son Top Ten 2025, les entreprises doivent prêter une attention particulière à quelques nouvelles catégories de risques, dont une toute nouvelle qui prouve, une fois pour toutes, que ce que vous ne savez pas peut effectivement vous nuire.
La nouvelle catégorie, Mauvaise gestion des conditions exceptionnelles, décrit ce qui peut se passer lorsque les organisations ne sont pas préparées à prévenir, détecter et répondre à des situations inhabituelles ou imprévisibles. Selon l'OWASP, cette vulnérabilité peut se déclencher lorsqu'une application n'empêche pas quelque chose d'inhabituel de se produire, n'identifie pas un problème lorsqu'il survient et/ou réagit mal ou pas du tout lorsqu'une situation inattendue se présente.
L'idée que les entreprises doivent être prêtes à faire face à ce qu'elles n'ont pas vu venir reflète la réalité des systèmes hautement distribués et interconnectés d'aujourd'hui. Et ce n'est pas comme si l'OWASP parlait de problèmes inédits - la mauvaise gestion des circonstances exceptionnelles contient 24 énumérations de faiblesses communes (CWE). C'est simplement que ces CWE, qui impliquent une mauvaise gestion des erreurs, l'impossibilité d'ouvrir des événements, des erreurs logiques et d'autres scénarios, peuvent se produire dans des conditions anormales. Cela peut résulter, par exemple, d'une validation inadéquate des entrées, d'erreurs de haut niveau dans les fonctions de traitement et d'un traitement incohérent (ou inexistant) des exceptions. Comme l'indique l'OWASP, "chaque fois qu'une application n'est pas sûre de sa prochaine instruction, une condition exceptionnelle a été mal gérée".
Ces circonstances exceptionnelles peuvent faire basculer les systèmes dans un état imprévisible, entraînant des pannes, des comportements inattendus et des vulnérabilités durables en matière de sécurité. Pour éviter ce type de perturbation, il faut essentiellement s'attendre au pire et prévoir de se préparer à l'imprévu.
Circonstances exceptionnelles et évolution du Top 10
La composition de la liste quadriennale des dix risques les plus graves pour la sécurité des applications web est restée relativement stable au fil des ans, avec quelques catégories qui se déplacent dans la liste et peut-être un ou deux ajouts tous les quatre ans. L'édition 2025 compte deux nouvelles entrées, dont la mauvaise gestion des conditions exceptionnelles, qui arrive en 10e position. L'autre catégorie, celle des défaillances de la chaîne d'approvisionnement en logiciels, qui occupe la troisième place, est une extension d'une catégorie antérieure, celle des composants vulnérables et obsolètes (n° 6 en 2021), qui comprend désormais un large éventail de compromissions logicielles. (Pour ceux qui comptent les points, le contrôle d'accès défaillant reste le risque numéro 1).
Les conditions exceptionnelles qui constituent la catégorie la plus récente peuvent créer une multitude de vulnérabilités, des bogues logiques aux débordements, et des transactions frauduleuses aux problèmes de mémoire, de synchronisation, d'authentification, d'autorisation et d'autres facteurs. Ces types de vulnérabilités peuvent avoir un impact sur la confidentialité, la disponibilité et l'intégrité d'un système ou de ses données. Elles permettent à un attaquant de manipuler le traitement défectueux des erreurs d'une application, par exemple, pour exploiter la vulnérabilité, a déclaré l'OWASP.
Un exemple d'incapacité à gérer des conditions inattendues est celui d'une application qui identifie des exceptions pendant le téléchargement de fichiers lors d'une attaque par déni de service, mais qui ne libère pas les ressources par la suite. Dans ce cas, les ressources restent bloquées ou indisponibles, ce qui entraîne l'épuisement des ressources. Si un pirate s'introduit dans une transaction financière en plusieurs étapes, un système qui n'annule pas la transaction lorsqu'une erreur est détectée peut permettre au pirate de vider le compte de l'utilisateur. Si une erreur est détectée au cours d'une transaction, il est très important de procéder à un "échec fermé", c'est-à-dire d'annuler toute la transaction et de la recommencer. Essayer de récupérer une transaction en cours de route peut créer des erreurs irrécupérables.
Défaut fermé ou défaut ouvert
Quelle est donc la différence entre ces deux actions ? Clarifions les choses :
Défaillance ouverte: si un système est "défaillant ouvert", il continue à fonctionner ou reste "ouvert" en cas de problème. Cette solution est utile lorsqu'il est très important que les choses continuent à fonctionner, mais elle peut être risquée en termes de sécurité.
Fermé par défaut: Si un système est "fermé par défaut", il s'arrête automatiquement ou se met en sécurité en cas de problème. Cette méthode est plus sûre du point de vue de la sécurité, car elle permet d'éviter les accès non autorisés.
Gestion des erreurs imprévues
Pour prévenir ce type de risque, il faut d'abord prévoir l'inconnu. Cela implique d'être en mesure de détecter toute erreur système possible lorsqu'elle se produit et de prendre des mesures pour résoudre le problème. Vous devez être en mesure d'informer correctement l'utilisateur (sans révéler d'informations critiques à l'attaquant), d'enregistrer l'événement et, le cas échéant, de lancer une alerte.
Voici un exemple de divulgation d'une erreur de requête SQL, ainsi que du chemin d'installation du site, qui peut être utilisé pour identifier un point d'injection :
Warning : odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:appindex_new.php on line 188
Dans l'idéal, un système devrait disposer d'un gestionnaire d'exception global pour détecter les erreurs négligées, ainsi que de fonctions telles que des outils de surveillance ou d'observabilité, ou d'une fonction qui détecte les erreurs répétées ou les schémas qui pourraient signaler une attaque en cours. Cela peut aider à se défendre contre les attaques visant à tirer parti des faiblesses de l'entreprise en matière de traitement des erreurs.
Pour une application web Java standard, par exemple, un gestionnaire d'erreurs global peut être configuré au niveau du descripteur de déploiement web.xml - dans ce cas, une configuration utilisée à partir de la version 2.5 de la spécification Servlet.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Ce petit bloc de code indique à une application web Java ce qu'il faut faire lorsque quelque chose ne va pas dans les coulisses. Au lieu d'afficher aux utilisateurs un message d'erreur confus ou un écran vide, il détecte discrètement le problème et les envoie vers une page d'erreur personnalisée. Dans ce cas, cette page serait error.jsp.
Parce qu'il est configuré pour gérer les types généraux d'exceptions java.lang.Exception, il agit comme un gestionnaire d'erreurs principal pour l'ensemble de l'application. Cela signifie que, quel que soit l'endroit où une erreur se produit, les utilisateurs seront redirigés vers la même page d'erreur conviviale et cohérente au lieu de voir des détails techniques bruts.
Prévenir l'inattendu
Dans l'idéal, les organisations devraient s'efforcer d'empêcher, autant que possible, que des conditions exceptionnelles ne se produisent. La mise en œuvre de limitations de débit, de quotas de ressources, d'étranglements et d'autres limites peut aider à lutter contre les attaques par déni de service et par force brute, par exemple. Vous voudrez peut-être identifier les erreurs répétées identiques et les inclure uniquement dans les statistiques, afin qu'elles n'interfèrent pas avec la journalisation et la surveillance automatisées. Un système doit également comprendre
une validation stricte des entrées, afin de garantir que seules des données correctement formées et assainies entrent dans le flux de travail. Elle doit intervenir tôt dans le flux de données, idéalement dès la réception des données.
Les meilleures pratiques en matière de traitement des erreurs, afin d'attraper les erreurs là où elles se produisent. Elles doivent être traitées efficacement : Indiquez clairement aux utilisateurs qu'ils doivent tenir un journal et envoyer des alertes si nécessaire. Un gestionnaire d'erreurs global est également idéal pour rattraper tout ce qui n'a pas été pris en compte.
La sécurité générale des transactions est également indispensable. Toujours "fail closed" : si quelque chose ne va pas, annulez l'ensemble de la transaction. Et n'essayez pas de réparer une transaction à mi-chemin, car cela peut entraîner des problèmes plus importants.
La centralisation de la journalisation, de la surveillance et des alertes, ainsi qu'un gestionnaire d'exception global, qui permet d'enquêter rapidement sur les incidents et d'uniformiser le processus de traitement des événements, tout en facilitant le respect des exigences de conformité.
Modélisation de la menace et/ou examen de la conception sécurisée, effectués au cours de la phase de conception des projets.
L'examen du code ou l'analyse statique, ainsi que les tests de stress, de performance et de pénétration effectués sur le système final.
La mauvaise gestion des conditions exceptionnelles est peut-être une nouvelle catégorie, mais elle fait appel à certains principes de base de la cybersécurité et souligne pourquoi les entreprises doivent être préparées à ce qu'elles n'anticipent pas nécessairement. Vous ne savez peut-être pas quelle forme prendront les conditions exceptionnelles, mais vous savez qu'elles se produiront. L'essentiel est d'être prêt à les gérer toutes de la même manière, ce qui facilitera la détection et la réponse à ces conditions lorsque l'inévitable se produira.
Note aux utilisateurs duSCW Trust Score™ :
Comme nous mettons à jour le contenu de notre Learning Platform pour l'aligner sur la norme OWASP Top 10 2025, il se peut que vous observiez des ajustements mineurs dans le score de confiance de vos développeurs Full Stack. N'hésitez pas à contacter votre représentant Customer Success si vous avez des questions ou si vous avez besoin d'aide.
.png)
Le Top 10 2025 de l'OWASP ajoute la mauvaise gestion des conditions exceptionnelles à la position 10. Atténuez les risques grâce à une logique "fail closed", à des gestionnaires d'erreurs globaux et à une validation stricte des entrées.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstration
Avec la publication par l'OWASP de son Top Ten 2025, les entreprises doivent prêter une attention particulière à quelques nouvelles catégories de risques, dont une toute nouvelle qui prouve, une fois pour toutes, que ce que vous ne savez pas peut effectivement vous nuire.
La nouvelle catégorie, Mauvaise gestion des conditions exceptionnelles, décrit ce qui peut se passer lorsque les organisations ne sont pas préparées à prévenir, détecter et répondre à des situations inhabituelles ou imprévisibles. Selon l'OWASP, cette vulnérabilité peut se déclencher lorsqu'une application n'empêche pas quelque chose d'inhabituel de se produire, n'identifie pas un problème lorsqu'il survient et/ou réagit mal ou pas du tout lorsqu'une situation inattendue se présente.
L'idée que les entreprises doivent être prêtes à faire face à ce qu'elles n'ont pas vu venir reflète la réalité des systèmes hautement distribués et interconnectés d'aujourd'hui. Et ce n'est pas comme si l'OWASP parlait de problèmes inédits - la mauvaise gestion des circonstances exceptionnelles contient 24 énumérations de faiblesses communes (CWE). C'est simplement que ces CWE, qui impliquent une mauvaise gestion des erreurs, l'impossibilité d'ouvrir des événements, des erreurs logiques et d'autres scénarios, peuvent se produire dans des conditions anormales. Cela peut résulter, par exemple, d'une validation inadéquate des entrées, d'erreurs de haut niveau dans les fonctions de traitement et d'un traitement incohérent (ou inexistant) des exceptions. Comme l'indique l'OWASP, "chaque fois qu'une application n'est pas sûre de sa prochaine instruction, une condition exceptionnelle a été mal gérée".
Ces circonstances exceptionnelles peuvent faire basculer les systèmes dans un état imprévisible, entraînant des pannes, des comportements inattendus et des vulnérabilités durables en matière de sécurité. Pour éviter ce type de perturbation, il faut essentiellement s'attendre au pire et prévoir de se préparer à l'imprévu.
Circonstances exceptionnelles et évolution du Top 10
La composition de la liste quadriennale des dix risques les plus graves pour la sécurité des applications web est restée relativement stable au fil des ans, avec quelques catégories qui se déplacent dans la liste et peut-être un ou deux ajouts tous les quatre ans. L'édition 2025 compte deux nouvelles entrées, dont la mauvaise gestion des conditions exceptionnelles, qui arrive en 10e position. L'autre catégorie, celle des défaillances de la chaîne d'approvisionnement en logiciels, qui occupe la troisième place, est une extension d'une catégorie antérieure, celle des composants vulnérables et obsolètes (n° 6 en 2021), qui comprend désormais un large éventail de compromissions logicielles. (Pour ceux qui comptent les points, le contrôle d'accès défaillant reste le risque numéro 1).
Les conditions exceptionnelles qui constituent la catégorie la plus récente peuvent créer une multitude de vulnérabilités, des bogues logiques aux débordements, et des transactions frauduleuses aux problèmes de mémoire, de synchronisation, d'authentification, d'autorisation et d'autres facteurs. Ces types de vulnérabilités peuvent avoir un impact sur la confidentialité, la disponibilité et l'intégrité d'un système ou de ses données. Elles permettent à un attaquant de manipuler le traitement défectueux des erreurs d'une application, par exemple, pour exploiter la vulnérabilité, a déclaré l'OWASP.
Un exemple d'incapacité à gérer des conditions inattendues est celui d'une application qui identifie des exceptions pendant le téléchargement de fichiers lors d'une attaque par déni de service, mais qui ne libère pas les ressources par la suite. Dans ce cas, les ressources restent bloquées ou indisponibles, ce qui entraîne l'épuisement des ressources. Si un pirate s'introduit dans une transaction financière en plusieurs étapes, un système qui n'annule pas la transaction lorsqu'une erreur est détectée peut permettre au pirate de vider le compte de l'utilisateur. Si une erreur est détectée au cours d'une transaction, il est très important de procéder à un "échec fermé", c'est-à-dire d'annuler toute la transaction et de la recommencer. Essayer de récupérer une transaction en cours de route peut créer des erreurs irrécupérables.
Défaut fermé ou défaut ouvert
Quelle est donc la différence entre ces deux actions ? Clarifions les choses :
Défaillance ouverte: si un système est "défaillant ouvert", il continue à fonctionner ou reste "ouvert" en cas de problème. Cette solution est utile lorsqu'il est très important que les choses continuent à fonctionner, mais elle peut être risquée en termes de sécurité.
Fermé par défaut: Si un système est "fermé par défaut", il s'arrête automatiquement ou se met en sécurité en cas de problème. Cette méthode est plus sûre du point de vue de la sécurité, car elle permet d'éviter les accès non autorisés.
Gestion des erreurs imprévues
Pour prévenir ce type de risque, il faut d'abord prévoir l'inconnu. Cela implique d'être en mesure de détecter toute erreur système possible lorsqu'elle se produit et de prendre des mesures pour résoudre le problème. Vous devez être en mesure d'informer correctement l'utilisateur (sans révéler d'informations critiques à l'attaquant), d'enregistrer l'événement et, le cas échéant, de lancer une alerte.
Voici un exemple de divulgation d'une erreur de requête SQL, ainsi que du chemin d'installation du site, qui peut être utilisé pour identifier un point d'injection :
Warning : odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:appindex_new.php on line 188
Dans l'idéal, un système devrait disposer d'un gestionnaire d'exception global pour détecter les erreurs négligées, ainsi que de fonctions telles que des outils de surveillance ou d'observabilité, ou d'une fonction qui détecte les erreurs répétées ou les schémas qui pourraient signaler une attaque en cours. Cela peut aider à se défendre contre les attaques visant à tirer parti des faiblesses de l'entreprise en matière de traitement des erreurs.
Pour une application web Java standard, par exemple, un gestionnaire d'erreurs global peut être configuré au niveau du descripteur de déploiement web.xml - dans ce cas, une configuration utilisée à partir de la version 2.5 de la spécification Servlet.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Ce petit bloc de code indique à une application web Java ce qu'il faut faire lorsque quelque chose ne va pas dans les coulisses. Au lieu d'afficher aux utilisateurs un message d'erreur confus ou un écran vide, il détecte discrètement le problème et les envoie vers une page d'erreur personnalisée. Dans ce cas, cette page serait error.jsp.
Parce qu'il est configuré pour gérer les types généraux d'exceptions java.lang.Exception, il agit comme un gestionnaire d'erreurs principal pour l'ensemble de l'application. Cela signifie que, quel que soit l'endroit où une erreur se produit, les utilisateurs seront redirigés vers la même page d'erreur conviviale et cohérente au lieu de voir des détails techniques bruts.
Prévenir l'inattendu
Dans l'idéal, les organisations devraient s'efforcer d'empêcher, autant que possible, que des conditions exceptionnelles ne se produisent. La mise en œuvre de limitations de débit, de quotas de ressources, d'étranglements et d'autres limites peut aider à lutter contre les attaques par déni de service et par force brute, par exemple. Vous voudrez peut-être identifier les erreurs répétées identiques et les inclure uniquement dans les statistiques, afin qu'elles n'interfèrent pas avec la journalisation et la surveillance automatisées. Un système doit également comprendre
une validation stricte des entrées, afin de garantir que seules des données correctement formées et assainies entrent dans le flux de travail. Elle doit intervenir tôt dans le flux de données, idéalement dès la réception des données.
Les meilleures pratiques en matière de traitement des erreurs, afin d'attraper les erreurs là où elles se produisent. Elles doivent être traitées efficacement : Indiquez clairement aux utilisateurs qu'ils doivent tenir un journal et envoyer des alertes si nécessaire. Un gestionnaire d'erreurs global est également idéal pour rattraper tout ce qui n'a pas été pris en compte.
La sécurité générale des transactions est également indispensable. Toujours "fail closed" : si quelque chose ne va pas, annulez l'ensemble de la transaction. Et n'essayez pas de réparer une transaction à mi-chemin, car cela peut entraîner des problèmes plus importants.
La centralisation de la journalisation, de la surveillance et des alertes, ainsi qu'un gestionnaire d'exception global, qui permet d'enquêter rapidement sur les incidents et d'uniformiser le processus de traitement des événements, tout en facilitant le respect des exigences de conformité.
Modélisation de la menace et/ou examen de la conception sécurisée, effectués au cours de la phase de conception des projets.
L'examen du code ou l'analyse statique, ainsi que les tests de stress, de performance et de pénétration effectués sur le système final.
La mauvaise gestion des conditions exceptionnelles est peut-être une nouvelle catégorie, mais elle fait appel à certains principes de base de la cybersécurité et souligne pourquoi les entreprises doivent être préparées à ce qu'elles n'anticipent pas nécessairement. Vous ne savez peut-être pas quelle forme prendront les conditions exceptionnelles, mais vous savez qu'elles se produiront. L'essentiel est d'être prêt à les gérer toutes de la même manière, ce qui facilitera la détection et la réponse à ces conditions lorsque l'inévitable se produira.
Note aux utilisateurs duSCW Trust Score™ :
Comme nous mettons à jour le contenu de notre Learning Platform pour l'aligner sur la norme OWASP Top 10 2025, il se peut que vous observiez des ajustements mineurs dans le score de confiance de vos développeurs Full Stack. N'hésitez pas à contacter votre représentant Customer Success si vous avez des questions ou si vous avez besoin d'aide.
Avec la publication par l'OWASP de son Top Ten 2025, les entreprises doivent prêter une attention particulière à quelques nouvelles catégories de risques, dont une toute nouvelle qui prouve, une fois pour toutes, que ce que vous ne savez pas peut effectivement vous nuire.
La nouvelle catégorie, Mauvaise gestion des conditions exceptionnelles, décrit ce qui peut se passer lorsque les organisations ne sont pas préparées à prévenir, détecter et répondre à des situations inhabituelles ou imprévisibles. Selon l'OWASP, cette vulnérabilité peut se déclencher lorsqu'une application n'empêche pas quelque chose d'inhabituel de se produire, n'identifie pas un problème lorsqu'il survient et/ou réagit mal ou pas du tout lorsqu'une situation inattendue se présente.
L'idée que les entreprises doivent être prêtes à faire face à ce qu'elles n'ont pas vu venir reflète la réalité des systèmes hautement distribués et interconnectés d'aujourd'hui. Et ce n'est pas comme si l'OWASP parlait de problèmes inédits - la mauvaise gestion des circonstances exceptionnelles contient 24 énumérations de faiblesses communes (CWE). C'est simplement que ces CWE, qui impliquent une mauvaise gestion des erreurs, l'impossibilité d'ouvrir des événements, des erreurs logiques et d'autres scénarios, peuvent se produire dans des conditions anormales. Cela peut résulter, par exemple, d'une validation inadéquate des entrées, d'erreurs de haut niveau dans les fonctions de traitement et d'un traitement incohérent (ou inexistant) des exceptions. Comme l'indique l'OWASP, "chaque fois qu'une application n'est pas sûre de sa prochaine instruction, une condition exceptionnelle a été mal gérée".
Ces circonstances exceptionnelles peuvent faire basculer les systèmes dans un état imprévisible, entraînant des pannes, des comportements inattendus et des vulnérabilités durables en matière de sécurité. Pour éviter ce type de perturbation, il faut essentiellement s'attendre au pire et prévoir de se préparer à l'imprévu.
Circonstances exceptionnelles et évolution du Top 10
La composition de la liste quadriennale des dix risques les plus graves pour la sécurité des applications web est restée relativement stable au fil des ans, avec quelques catégories qui se déplacent dans la liste et peut-être un ou deux ajouts tous les quatre ans. L'édition 2025 compte deux nouvelles entrées, dont la mauvaise gestion des conditions exceptionnelles, qui arrive en 10e position. L'autre catégorie, celle des défaillances de la chaîne d'approvisionnement en logiciels, qui occupe la troisième place, est une extension d'une catégorie antérieure, celle des composants vulnérables et obsolètes (n° 6 en 2021), qui comprend désormais un large éventail de compromissions logicielles. (Pour ceux qui comptent les points, le contrôle d'accès défaillant reste le risque numéro 1).
Les conditions exceptionnelles qui constituent la catégorie la plus récente peuvent créer une multitude de vulnérabilités, des bogues logiques aux débordements, et des transactions frauduleuses aux problèmes de mémoire, de synchronisation, d'authentification, d'autorisation et d'autres facteurs. Ces types de vulnérabilités peuvent avoir un impact sur la confidentialité, la disponibilité et l'intégrité d'un système ou de ses données. Elles permettent à un attaquant de manipuler le traitement défectueux des erreurs d'une application, par exemple, pour exploiter la vulnérabilité, a déclaré l'OWASP.
Un exemple d'incapacité à gérer des conditions inattendues est celui d'une application qui identifie des exceptions pendant le téléchargement de fichiers lors d'une attaque par déni de service, mais qui ne libère pas les ressources par la suite. Dans ce cas, les ressources restent bloquées ou indisponibles, ce qui entraîne l'épuisement des ressources. Si un pirate s'introduit dans une transaction financière en plusieurs étapes, un système qui n'annule pas la transaction lorsqu'une erreur est détectée peut permettre au pirate de vider le compte de l'utilisateur. Si une erreur est détectée au cours d'une transaction, il est très important de procéder à un "échec fermé", c'est-à-dire d'annuler toute la transaction et de la recommencer. Essayer de récupérer une transaction en cours de route peut créer des erreurs irrécupérables.
Défaut fermé ou défaut ouvert
Quelle est donc la différence entre ces deux actions ? Clarifions les choses :
Défaillance ouverte: si un système est "défaillant ouvert", il continue à fonctionner ou reste "ouvert" en cas de problème. Cette solution est utile lorsqu'il est très important que les choses continuent à fonctionner, mais elle peut être risquée en termes de sécurité.
Fermé par défaut: Si un système est "fermé par défaut", il s'arrête automatiquement ou se met en sécurité en cas de problème. Cette méthode est plus sûre du point de vue de la sécurité, car elle permet d'éviter les accès non autorisés.
Gestion des erreurs imprévues
Pour prévenir ce type de risque, il faut d'abord prévoir l'inconnu. Cela implique d'être en mesure de détecter toute erreur système possible lorsqu'elle se produit et de prendre des mesures pour résoudre le problème. Vous devez être en mesure d'informer correctement l'utilisateur (sans révéler d'informations critiques à l'attaquant), d'enregistrer l'événement et, le cas échéant, de lancer une alerte.
Voici un exemple de divulgation d'une erreur de requête SQL, ainsi que du chemin d'installation du site, qui peut être utilisé pour identifier un point d'injection :
Warning : odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:appindex_new.php on line 188
Dans l'idéal, un système devrait disposer d'un gestionnaire d'exception global pour détecter les erreurs négligées, ainsi que de fonctions telles que des outils de surveillance ou d'observabilité, ou d'une fonction qui détecte les erreurs répétées ou les schémas qui pourraient signaler une attaque en cours. Cela peut aider à se défendre contre les attaques visant à tirer parti des faiblesses de l'entreprise en matière de traitement des erreurs.
Pour une application web Java standard, par exemple, un gestionnaire d'erreurs global peut être configuré au niveau du descripteur de déploiement web.xml - dans ce cas, une configuration utilisée à partir de la version 2.5 de la spécification Servlet.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Ce petit bloc de code indique à une application web Java ce qu'il faut faire lorsque quelque chose ne va pas dans les coulisses. Au lieu d'afficher aux utilisateurs un message d'erreur confus ou un écran vide, il détecte discrètement le problème et les envoie vers une page d'erreur personnalisée. Dans ce cas, cette page serait error.jsp.
Parce qu'il est configuré pour gérer les types généraux d'exceptions java.lang.Exception, il agit comme un gestionnaire d'erreurs principal pour l'ensemble de l'application. Cela signifie que, quel que soit l'endroit où une erreur se produit, les utilisateurs seront redirigés vers la même page d'erreur conviviale et cohérente au lieu de voir des détails techniques bruts.
Prévenir l'inattendu
Dans l'idéal, les organisations devraient s'efforcer d'empêcher, autant que possible, que des conditions exceptionnelles ne se produisent. La mise en œuvre de limitations de débit, de quotas de ressources, d'étranglements et d'autres limites peut aider à lutter contre les attaques par déni de service et par force brute, par exemple. Vous voudrez peut-être identifier les erreurs répétées identiques et les inclure uniquement dans les statistiques, afin qu'elles n'interfèrent pas avec la journalisation et la surveillance automatisées. Un système doit également comprendre
une validation stricte des entrées, afin de garantir que seules des données correctement formées et assainies entrent dans le flux de travail. Elle doit intervenir tôt dans le flux de données, idéalement dès la réception des données.
Les meilleures pratiques en matière de traitement des erreurs, afin d'attraper les erreurs là où elles se produisent. Elles doivent être traitées efficacement : Indiquez clairement aux utilisateurs qu'ils doivent tenir un journal et envoyer des alertes si nécessaire. Un gestionnaire d'erreurs global est également idéal pour rattraper tout ce qui n'a pas été pris en compte.
La sécurité générale des transactions est également indispensable. Toujours "fail closed" : si quelque chose ne va pas, annulez l'ensemble de la transaction. Et n'essayez pas de réparer une transaction à mi-chemin, car cela peut entraîner des problèmes plus importants.
La centralisation de la journalisation, de la surveillance et des alertes, ainsi qu'un gestionnaire d'exception global, qui permet d'enquêter rapidement sur les incidents et d'uniformiser le processus de traitement des événements, tout en facilitant le respect des exigences de conformité.
Modélisation de la menace et/ou examen de la conception sécurisée, effectués au cours de la phase de conception des projets.
L'examen du code ou l'analyse statique, ainsi que les tests de stress, de performance et de pénétration effectués sur le système final.
La mauvaise gestion des conditions exceptionnelles est peut-être une nouvelle catégorie, mais elle fait appel à certains principes de base de la cybersécurité et souligne pourquoi les entreprises doivent être préparées à ce qu'elles n'anticipent pas nécessairement. Vous ne savez peut-être pas quelle forme prendront les conditions exceptionnelles, mais vous savez qu'elles se produiront. L'essentiel est d'être prêt à les gérer toutes de la même manière, ce qui facilitera la détection et la réponse à ces conditions lorsque l'inévitable se produira.
Note aux utilisateurs duSCW Trust Score™ :
Comme nous mettons à jour le contenu de notre Learning Platform pour l'aligner sur la norme OWASP Top 10 2025, il se peut que vous observiez des ajustements mineurs dans le score de confiance de vos développeurs Full Stack. N'hésitez pas à contacter votre représentant Customer Success si vous avez des questions ou si vous avez besoin d'aide.
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstration
Avec la publication par l'OWASP de son Top Ten 2025, les entreprises doivent prêter une attention particulière à quelques nouvelles catégories de risques, dont une toute nouvelle qui prouve, une fois pour toutes, que ce que vous ne savez pas peut effectivement vous nuire.
La nouvelle catégorie, Mauvaise gestion des conditions exceptionnelles, décrit ce qui peut se passer lorsque les organisations ne sont pas préparées à prévenir, détecter et répondre à des situations inhabituelles ou imprévisibles. Selon l'OWASP, cette vulnérabilité peut se déclencher lorsqu'une application n'empêche pas quelque chose d'inhabituel de se produire, n'identifie pas un problème lorsqu'il survient et/ou réagit mal ou pas du tout lorsqu'une situation inattendue se présente.
L'idée que les entreprises doivent être prêtes à faire face à ce qu'elles n'ont pas vu venir reflète la réalité des systèmes hautement distribués et interconnectés d'aujourd'hui. Et ce n'est pas comme si l'OWASP parlait de problèmes inédits - la mauvaise gestion des circonstances exceptionnelles contient 24 énumérations de faiblesses communes (CWE). C'est simplement que ces CWE, qui impliquent une mauvaise gestion des erreurs, l'impossibilité d'ouvrir des événements, des erreurs logiques et d'autres scénarios, peuvent se produire dans des conditions anormales. Cela peut résulter, par exemple, d'une validation inadéquate des entrées, d'erreurs de haut niveau dans les fonctions de traitement et d'un traitement incohérent (ou inexistant) des exceptions. Comme l'indique l'OWASP, "chaque fois qu'une application n'est pas sûre de sa prochaine instruction, une condition exceptionnelle a été mal gérée".
Ces circonstances exceptionnelles peuvent faire basculer les systèmes dans un état imprévisible, entraînant des pannes, des comportements inattendus et des vulnérabilités durables en matière de sécurité. Pour éviter ce type de perturbation, il faut essentiellement s'attendre au pire et prévoir de se préparer à l'imprévu.
Circonstances exceptionnelles et évolution du Top 10
La composition de la liste quadriennale des dix risques les plus graves pour la sécurité des applications web est restée relativement stable au fil des ans, avec quelques catégories qui se déplacent dans la liste et peut-être un ou deux ajouts tous les quatre ans. L'édition 2025 compte deux nouvelles entrées, dont la mauvaise gestion des conditions exceptionnelles, qui arrive en 10e position. L'autre catégorie, celle des défaillances de la chaîne d'approvisionnement en logiciels, qui occupe la troisième place, est une extension d'une catégorie antérieure, celle des composants vulnérables et obsolètes (n° 6 en 2021), qui comprend désormais un large éventail de compromissions logicielles. (Pour ceux qui comptent les points, le contrôle d'accès défaillant reste le risque numéro 1).
Les conditions exceptionnelles qui constituent la catégorie la plus récente peuvent créer une multitude de vulnérabilités, des bogues logiques aux débordements, et des transactions frauduleuses aux problèmes de mémoire, de synchronisation, d'authentification, d'autorisation et d'autres facteurs. Ces types de vulnérabilités peuvent avoir un impact sur la confidentialité, la disponibilité et l'intégrité d'un système ou de ses données. Elles permettent à un attaquant de manipuler le traitement défectueux des erreurs d'une application, par exemple, pour exploiter la vulnérabilité, a déclaré l'OWASP.
Un exemple d'incapacité à gérer des conditions inattendues est celui d'une application qui identifie des exceptions pendant le téléchargement de fichiers lors d'une attaque par déni de service, mais qui ne libère pas les ressources par la suite. Dans ce cas, les ressources restent bloquées ou indisponibles, ce qui entraîne l'épuisement des ressources. Si un pirate s'introduit dans une transaction financière en plusieurs étapes, un système qui n'annule pas la transaction lorsqu'une erreur est détectée peut permettre au pirate de vider le compte de l'utilisateur. Si une erreur est détectée au cours d'une transaction, il est très important de procéder à un "échec fermé", c'est-à-dire d'annuler toute la transaction et de la recommencer. Essayer de récupérer une transaction en cours de route peut créer des erreurs irrécupérables.
Défaut fermé ou défaut ouvert
Quelle est donc la différence entre ces deux actions ? Clarifions les choses :
Défaillance ouverte: si un système est "défaillant ouvert", il continue à fonctionner ou reste "ouvert" en cas de problème. Cette solution est utile lorsqu'il est très important que les choses continuent à fonctionner, mais elle peut être risquée en termes de sécurité.
Fermé par défaut: Si un système est "fermé par défaut", il s'arrête automatiquement ou se met en sécurité en cas de problème. Cette méthode est plus sûre du point de vue de la sécurité, car elle permet d'éviter les accès non autorisés.
Gestion des erreurs imprévues
Pour prévenir ce type de risque, il faut d'abord prévoir l'inconnu. Cela implique d'être en mesure de détecter toute erreur système possible lorsqu'elle se produit et de prendre des mesures pour résoudre le problème. Vous devez être en mesure d'informer correctement l'utilisateur (sans révéler d'informations critiques à l'attaquant), d'enregistrer l'événement et, le cas échéant, de lancer une alerte.
Voici un exemple de divulgation d'une erreur de requête SQL, ainsi que du chemin d'installation du site, qui peut être utilisé pour identifier un point d'injection :
Warning : odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:appindex_new.php on line 188
Dans l'idéal, un système devrait disposer d'un gestionnaire d'exception global pour détecter les erreurs négligées, ainsi que de fonctions telles que des outils de surveillance ou d'observabilité, ou d'une fonction qui détecte les erreurs répétées ou les schémas qui pourraient signaler une attaque en cours. Cela peut aider à se défendre contre les attaques visant à tirer parti des faiblesses de l'entreprise en matière de traitement des erreurs.
Pour une application web Java standard, par exemple, un gestionnaire d'erreurs global peut être configuré au niveau du descripteur de déploiement web.xml - dans ce cas, une configuration utilisée à partir de la version 2.5 de la spécification Servlet.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
...
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
...
</web-app>
Ce petit bloc de code indique à une application web Java ce qu'il faut faire lorsque quelque chose ne va pas dans les coulisses. Au lieu d'afficher aux utilisateurs un message d'erreur confus ou un écran vide, il détecte discrètement le problème et les envoie vers une page d'erreur personnalisée. Dans ce cas, cette page serait error.jsp.
Parce qu'il est configuré pour gérer les types généraux d'exceptions java.lang.Exception, il agit comme un gestionnaire d'erreurs principal pour l'ensemble de l'application. Cela signifie que, quel que soit l'endroit où une erreur se produit, les utilisateurs seront redirigés vers la même page d'erreur conviviale et cohérente au lieu de voir des détails techniques bruts.
Prévenir l'inattendu
Dans l'idéal, les organisations devraient s'efforcer d'empêcher, autant que possible, que des conditions exceptionnelles ne se produisent. La mise en œuvre de limitations de débit, de quotas de ressources, d'étranglements et d'autres limites peut aider à lutter contre les attaques par déni de service et par force brute, par exemple. Vous voudrez peut-être identifier les erreurs répétées identiques et les inclure uniquement dans les statistiques, afin qu'elles n'interfèrent pas avec la journalisation et la surveillance automatisées. Un système doit également comprendre
une validation stricte des entrées, afin de garantir que seules des données correctement formées et assainies entrent dans le flux de travail. Elle doit intervenir tôt dans le flux de données, idéalement dès la réception des données.
Les meilleures pratiques en matière de traitement des erreurs, afin d'attraper les erreurs là où elles se produisent. Elles doivent être traitées efficacement : Indiquez clairement aux utilisateurs qu'ils doivent tenir un journal et envoyer des alertes si nécessaire. Un gestionnaire d'erreurs global est également idéal pour rattraper tout ce qui n'a pas été pris en compte.
La sécurité générale des transactions est également indispensable. Toujours "fail closed" : si quelque chose ne va pas, annulez l'ensemble de la transaction. Et n'essayez pas de réparer une transaction à mi-chemin, car cela peut entraîner des problèmes plus importants.
La centralisation de la journalisation, de la surveillance et des alertes, ainsi qu'un gestionnaire d'exception global, qui permet d'enquêter rapidement sur les incidents et d'uniformiser le processus de traitement des événements, tout en facilitant le respect des exigences de conformité.
Modélisation de la menace et/ou examen de la conception sécurisée, effectués au cours de la phase de conception des projets.
L'examen du code ou l'analyse statique, ainsi que les tests de stress, de performance et de pénétration effectués sur le système final.
La mauvaise gestion des conditions exceptionnelles est peut-être une nouvelle catégorie, mais elle fait appel à certains principes de base de la cybersécurité et souligne pourquoi les entreprises doivent être préparées à ce qu'elles n'anticipent pas nécessairement. Vous ne savez peut-être pas quelle forme prendront les conditions exceptionnelles, mais vous savez qu'elles se produiront. L'essentiel est d'être prêt à les gérer toutes de la même manière, ce qui facilitera la détection et la réponse à ces conditions lorsque l'inévitable se produira.
Note aux utilisateurs duSCW Trust Score™ :
Comme nous mettons à jour le contenu de notre Learning Platform pour l'aligner sur la norme OWASP Top 10 2025, il se peut que vous observiez des ajustements mineurs dans le score de confiance de vos développeurs Full Stack. N'hésitez pas à contacter votre représentant Customer Success si vous avez des questions ou si vous avez besoin d'aide.
Table des matières
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
.png)
.png)
Le pouvoir de la marque dans l'AppSec DevSec DevSecOps (Qu'est-ce qu'un acronyme ?)
Dans le domaine de l'AppSec, l'impact durable d'un programme exige plus que de la technologie : il faut une marque forte. Une identité forte garantit que vos initiatives trouvent un écho et suscitent un engagement durable au sein de votre communauté de développeurs.
Ressources pour vous aider à démarrer
OWASP Top 10 2025 : Défaillances de la chaîne d'approvisionnement en logiciels
Le Top 10 2025 de l'OWASP place les défaillances de la chaîne d'approvisionnement des logiciels en troisième position. Atténuez ce risque à fort impact grâce à des SBOM stricts, au suivi des dépendances et au renforcement du pipeline CI/CD.
OWASP Top 10 : 2025 - Quoi de neuf et comment Secure Code Warrior vous aide à rester aligné
Découvrez ce qui a changé dans le Top 10 de l'OWASP : 2025 et comment Secure Code Warrior facilite la transition grâce à la mise à jour des quêtes, des Courses et des informations destinées aux développeurs.
Adoptez rapidement l'IA agentique dans le développement de logiciels ! (Spoiler : Vous ne devriez probablement pas.)
Le monde de la cybersécurité va-t-il trop vite en matière d'IA agentique ? L'avenir de la sécurité de l'IA est là, et il est temps pour les experts de passer de la réflexion à la réalité.
Résoudre la crise de la visibilité : comment l'agent de confiance comble le fossé entre l'apprentissage et le code
Trust Agent de Secure Code Warrior résout la crise du codage sécurisé en validant les compétences des développeurs à chaque livraison. Il découvre tous les contributeurs et automatise la gouvernance dans votre flux de travail de développement.
Codage axé sur le développeur.
En toute sécurité.
Contactez-nous dès aujourd'hui et faites de la sécurité des logiciels une partie intrinsèque de votre processus de développement.
