Le code d’une application n’est jamais neutre : c’est une surface d’attaque qui s’étend à chaque fonctionnalité ajoutée, et une dépendance de plus, c’est un vecteur de plus, importé sans qu’on l’ait vraiment audité. La rubrique part de là : OWASP n’est pas une liste à cocher pour rassurer un audit, c’est la cartographie des façons les plus courantes de se faire avoir, côté web comme côté API.
Une API mal pensée ouvre les mêmes portes qu’une application web classique, avec une différence de taille : personne ne relit un endpoint interne « juste utilisé par le frontend », jusqu’au jour où quelqu’un d’autre le trouve. Injection, désérialisation, contrôle d’accès qui suppose que seul un client légitime enverra une requête légitime (BOLA en tête) : le sujet est moins la faille elle-même que l’angle mort qui la rend invisible en revue.
En amont, il y a la chaîne logicielle : un SBOM qui liste ce qui tourne vraiment, des dépendances transitives dont personne ne connaît le mainteneur, un build qui n’est reproductible que sur le papier. Et en continu, l’usine qui produit tout ça : un pipeline CI/CD, des secrets qui y traînent plus longtemps qu’ils ne devraient, un compte de service qui garde les mêmes droits depuis trois ans parce que personne n’ose y toucher.
Le poste développeur fait aussi partie du terrain : cible privilégiée depuis qu’il vaut mieux compromettre la source que le produit fini, et la préprod, sanctuaire d’oubli où traînent des données de test qui n’ont jamais été vraiment anonymisées.
Une organisation qui néglige ce domaine ne sait tout simplement pas ce qu’elle exécute. Sans inventaire des composants, l’annonce d’une faille dans une bibliothèque répandue déclenche une chasse manuelle de plusieurs jours, pendant que l’exploitation, elle, s’automatise dès les premières heures. Un secret oublié dans le pipeline ou un compte de service aux droits jamais revus offre à qui le trouve le pouvoir de publier en production, avec la signature de l’usine elle-même : le code malveillant arrive alors par le canal le plus légitime qui soit, et les journaux enregistrent un déploiement parfaitement ordinaire.
Une application est un programme qui reçoit des demandes et y répond. Chaque fonctionnalité ajoutée crée de nouveaux points d’entrée, donc de nouvelles occasions pour un attaquant d’envoyer des données piégées. L’OWASP, une communauté ouverte consacrée à la sécurité des applications, recense les erreurs les plus fréquentes. L’injection se produit quand une donnée fournie par l’utilisateur est exécutée comme une commande. La désérialisation dangereuse survient quand l’application reconstruit des objets à partir de données reçues sans les contrôler. Le contrôle d’accès échoue quand l’application suppose que seul un client honnête enverra des requêtes : en changeant simplement le numéro d’un objet demandé, un utilisateur obtient celui d’un autre. Les interfaces de programmation, ou API, par lesquelles les logiciels dialoguent entre eux, présentent les mêmes défauts, souvent moins relus. En amont, une application assemble de nombreux composants écrits par d’autres, qui dépendent eux-mêmes d’autres composants. Une nomenclature logicielle en dresse la liste réelle. Le code est ensuite compilé et déployé par une chaîne automatique, le pipeline, qui manipule des secrets et des comptes de service puissants : s’ils fuient ou gardent trop de droits, un attaquant peut modifier ce qui part en production. Le poste du développeur est une cible, car compromettre le code source touche tous les utilisateurs du produit. Enfin, les environnements de test contiennent parfois de vraies données mal anonymisées.
