Formation sécurité offensive pour développeurs : penser comme un attaquant plutôt que cocher une checklist

Une distinction structurante : sensibilisation généraliste et formation offensive pour développeurs

La sensibilisation cybersécurité classique et la formation à la sécurité offensive pour développeurs répondent à deux problèmes différents, avec des méthodes différentes, même si les deux relèvent du même objectif général de réduction du risque.

La sensibilisation généraliste vise un public large, sans prérequis technique, sur des sujets transverses à toute l’organisation. Elle repose typiquement sur des simulations de phishing, des modules de e-learning et des rappels de bonnes pratiques. Sa limite structurelle est qu’elle ne touche jamais le code lui-même, puisque ce n’est pas son objet.

La formation offensive pour développeurs vise un public technique, avec un prérequis de compétence en développement, sur les vulnérabilités que le code produit lui-même. Elle repose sur des référentiels construits par et pour la communauté du développement sécurisé.

Le référentiel de référence côté web est l’OWASP Top 10, publié par l’Open Worldwide Application Security Project, une fondation à but non lucratif. Sa dernière édition majeure, le Top 10:2025, a été présentée en novembre 2025 lors de la conférence Global AppSec à Washington, la première mise à jour depuis 2021. Elle s’appuie sur des données couvrant plus de 2,8 millions d’applications testées. Deux nouvelles catégories y font leur apparition, les défaillances de la chaîne logicielle et la mauvaise gestion des conditions exceptionnelles, tandis que la SSRF a été fusionnée dans le contrôle d’accès défaillant.

Le référentiel de référence côté mobile est le MASVS, le Mobile Application Security Verification Standard, maintenu par le projet OWASP Mobile Application Security. Il organise les exigences de sécurité mobile en huit catégories, le stockage des données sensibles, la cryptographie, l’authentification, les communications réseau, l’interaction avec la plateforme, les bonnes pratiques de code, la résilience face à la rétro-ingénierie, et la protection de la vie privée.

Ces deux référentiels ne sont ni des normes réglementaires ni des certifications. Ce sont des documents de sensibilisation technique, construits sur l’observation de vulnérabilités réelles, qui donnent un vocabulaire commun aux développeurs, aux testeurs et aux équipes de sécurité pour parler du même problème de la même façon.

Comment ça s’articule en mission : vue du pentester

Pour un pentester qui audite une application web ou mobile, les référentiels OWASP ne sont pas une abstraction théorique, ils correspondent presque systématiquement à ce qui est trouvé sur le terrain.

Prenons un exemple représentatif d’un test d’intrusion applicatif web. L’application expose un endpoint qui permet de consulter le détail d’une commande via son identifiant, sous la forme /api/commandes/1234. Le développeur a correctement vérifié que l’utilisateur était authentifié, mais n’a jamais vérifié que la commande demandée appartenait bien à cet utilisateur. En modifiant simplement l’identifiant dans l’URL, un pentester accède aux commandes de n’importe quel autre client. C’est un cas d’école de contrôle d’accès défaillant, la catégorie la plus fréquemment observée dans les données du Top 10:2025, et connue sous le nom d’IDOR, Insecure Direct Object Reference, dans le vocabulaire des testeurs.

Côté mobile, un exemple tout aussi courant concerne le stockage local. Une application stocke un jeton de session ou des données personnelles dans un fichier accessible sans chiffrement sur l’appareil, ou dans les logs système consultables par toute application disposant des permissions adéquates. C’est directement ce que couvre la catégorie MASVS-STORAGE, et c’est l’un des tout premiers points vérifiés lors d’un test d’intrusion mobile, avant même de s’intéresser aux communications réseau de l’application.

Ce que révèle systématiquement ce type de constat, c’est que la faille ne provient presque jamais d’un outil ou d’une technologie défaillante. Elle provient d’une hypothèse de conception que le développeur n’a jamais eu l’occasion de remettre en question, faute d’avoir vu, au moment où il écrivait le code, comment cette même ligne pouvait être détournée par quelqu’un qui cherche activement à la casser.

Vue développeur : le même référentiel lu dans l’autre sens

L’intérêt de la sécurité offensive pour développeurs tient précisément à cette réversibilité. Les mêmes référentiels qui structurent le travail du pentester structurent aussi la façon d’enseigner la remédiation, à condition de les enseigner dans le bon ordre, l’attaque avant la correction, plutôt que l’inverse.

Face à un contrôle d’accès défaillant, l’enseignement classique consiste à dire au développeur qu’il faut vérifier les autorisations côté serveur. L’enseignement par la sécurité offensive consiste d’abord à lui faire exploiter lui-même une IDOR sur une application volontairement vulnérable, pour qu’il ressente concrètement pourquoi une vérification côté client ne protège jamais rien, avant même d’aborder la correction. L’ordre importe, un développeur qui a manipulé lui-même l’identifiant dans l’URL retient la logique de la faille bien plus durablement qu’un développeur qui a seulement lu une règle de bonne pratique dans un document de référence.

Cette approche fonctionne de la même façon côté mobile. Face à une catégorie MASVS-CRYPTO mal implémentée, faire décompiler à un développeur une application qui utilise un algorithme de chiffrement obsolète, ou une clé codée en dur dans le binaire, ancre la notion de résilience face à la rétro-ingénierie bien plus efficacement qu’une simple recommandation d’utiliser une bibliothèque cryptographique à jour.

C’est exactement l’angle sur lequel repose la formation à la sécurité offensive pour développeurs web et mobile de PIIRATES, certifiée Qualiopi. Plutôt que de dérouler une liste de bonnes pratiques à appliquer, elle place les équipes de développement en situation d’exploiter des vulnérabilités réelles, mappées sur les catégories de l’OWASP Top 10 et du MASVS, avant de leur montrer comment corriger ce qu’elles viennent d’exploiter elles-mêmes.

Les limites de ces référentiels, une lecture honnête

Ni l’OWASP Top 10 ni le MASVS ne doivent être présentés comme une garantie de sécurité une fois leurs catégories couvertes.

Un référentiel mis à jour tous les quatre ans reste un instantané. Le Top 10 précédent datait de 2021, l’édition 2025 est la première refonte en quatre ans. Entre deux éditions, des classes de vulnérabilités émergentes peuvent rester sous-représentées dans le classement, alors qu’elles sont déjà activement exploitées sur le terrain.

Dix catégories ne couvrent jamais l’intégralité de la surface d’attaque applicative. Le Top 10 est construit comme un outil de priorisation, pas comme un inventaire exhaustif. Une application peut cocher les dix catégories et rester vulnérable à une faille de logique métier propre à son fonctionnement, un type de vulnérabilité que ces référentiels décrivent mal, précisément parce qu’elle dépend du contexte fonctionnel de chaque application.

Une formation ponctuelle s’estompe si elle n’est jamais reconduite. La mémoire d’un réflexe de sécurité codé, comme celle de tout apprentissage technique, décroît avec le temps si elle n’est pas régulièrement remise à l’épreuve sur du code réel. Une session de formation isolée, même excellente, a une durée de vie limitée si elle n’est pas relayée par une pratique continue.

Ces référentiels ne remplacent jamais un test d’intrusion réel. Un développeur formé au contrôle d’accès défaillant continuera d’écrire du code, mais rien ne garantit qu’il aura pensé à ce pattern précis dans une fonctionnalité complexe livrée sous pression de délai. C’est précisément la raison pour laquelle la formation des développeurs et le test d’intrusion applicatif ne sont jamais substituables l’un à l’autre, mais complémentaires.

Le positionnement de PIIRATES

Nous nous appuyons sur l’OWASP Top 10 et le MASVS comme structure pédagogique pour nos formations, parce qu’ils offrent un vocabulaire déjà partagé par la communauté du développement sécurisé, mais nous ne les traitons jamais comme une liste à réciter. Notre formation développeur web et mobile est construite autour de mises en situation offensives réelles, directement issues de constats observés lors de nos missions de test d’intrusion, plutôt qu’autour de cas d’école génériques.

L’objectif n’est pas de transformer chaque développeur en pentester. C’est de leur donner suffisamment d’expérience offensive concrète pour qu’ils reconnaissent, au moment où ils écrivent une ligne de code, le pattern qui rendrait cette ligne exploitable, avant qu’un audit ou une intrusion réelle n’ait à le leur montrer.

Cette formation vient en complément naturel de nos missions de test d’intrusion applicatif, pas en substitut. Une équipe de développement formée produit un code plus robuste en amont, ce qui réduit le volume et la sévérité des constats relevés lors d’un audit, sans jamais garantir leur disparition totale, un test d’intrusion reste nécessaire pour valider ce qui a réellement été corrigé, et ce qui subsiste malgré la formation.