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.
.avif)
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 là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver 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.
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Consulter le rapportRéserver 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 là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationTéléchargerRessources pour débuter
Thèmes et contenus de la formation Securecode
Nos contenus de pointe sont constamment développés afin de s'adapter à l'évolution constante du paysage du développement logiciel, en tenant compte de votre rôle. Les thèmes abordés couvrent tous les domaines, de l'IA à l'injection XQuery, et sont proposés pour une multitude de rôles, des architectes et ingénieurs aux chefs de produit et responsables assurance qualité. Nous vous invitons à découvrir un aperçu de notre catalogue de contenus classés par thème et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
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.
Ressources pour débuter
Cybermon est de retour : les missions KI « Beat the Boss » sont désormais disponibles sur demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Il utilise des exigences de sécurité IA/LLM avancées pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes de développement peuvent s'y préparer en adoptant des méthodes sécurisées, en prévenant les failles de sécurité et en renforçant les compétences des développeurs.
Facteur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en dix parties intitulée « Les catalyseurs de la réussite » et démontre comment un codage sécurisé peut être associé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'atteindre une maturité programmatique à long terme.
