Méthodologies
OWASP
L’OWASP (Open Worldwide Application Security Project) publie les référentiels de sécurité applicative les plus utilisés au monde. Ils sont ouverts, gratuits et vérifiables par n’importe qui : c’est pourquoi nos tests d’intrusion s’appuient dessus plutôt que sur une grille maison.
Cette page explique l’OWASP Top 10:2025 catégorie par catégorie, en français, puis décrit ce que nous en faisons pendant une mission. Elle fait partie de nos méthodologies de test.
Ils nous font confiance
OWASP
Qu’est-ce que l’OWASP ?
L’OWASP — Open Worldwide Application Security Project — est une fondation à but non lucratif créée en 2001. Elle ne vend pas d’outil et ne certifie personne : elle publie, avec une communauté de praticiens, des documents de référence sur la façon de concevoir, de vérifier et d’attaquer une application. Le Top 10, l’ASVS, le WSTG, le MASTG et le SAMM en sont les pièces les plus connues.
Pour nous, l’OWASP n’est pas une liste à cocher en fin de mission : c’est le vocabulaire commun entre vos développeurs, votre RSSI, votre auditeur et nos pentesteurs. Lorsqu’un rapport indique « A01:2025 – Broken Access Control », chacun relit la définition publique, situe le constat et compare deux missions à deux ans d’intervalle sans rediscuter de ce qui a été testé.
Objectifs
Objectifs : ce que l’OWASP apporte à votre test d’intrusion
Un test d’intrusion sans référentiel produit une liste de constats dont personne ne sait si elle est complète. Adosser la mission à l’OWASP répond aux quatre questions que vos clients finissent toujours par poser : qu’avez-vous testé, dans quel ordre, avec quelle profondeur, et comment le vérifier.
Prioriser sur le risque réel
Le Top 10 est construit à partir de données remontées par des centaines d’organisations. Commencer par ces catégories, c’est commencer par les défauts qui provoquent des compromissions, pas par ceux qui sont les plus faciles à détecter.
Rendre la couverture vérifiable
Chaque constat porte une catégorie publique. Votre auditeur ou votre client grand compte lit la même définition que nous et constate ce qui a été couvert — et ce qui ne l’a pas été, parce que hors périmètre.
Parler la langue de vos développeurs
Les catégories OWASP s’intègrent telles quelles dans un ticket Jira ou GitLab : l’équipe ouvre un ticket par constat, étapes de reproduction comprises, sans traduire notre rapport.
Comparer dans le temps
Une mission annuelle sur le même référentiel devient une mesure : vous voyez ce qui a disparu, ce qui est réapparu et ce qu’ont introduit les nouvelles fonctionnalités.
OWASP Top 10
OWASP Top 10:2025 : les dix catégories expliquées en français
Le Top 10 recense les dix risques les plus sérieux pour les applications web. La liste est révisée tous les trois à quatre ans ; la version en vigueur est celle de 2025, qui introduit deux catégories nouvelles et en redistribue plusieurs anciennes.
Les intitulés restent en anglais, volontairement : ce sont eux qui figureront dans votre rapport, dans vos tickets et dans vos réponses aux questionnaires de sécurité. Nous donnons la traduction entre parenthèses, puis l’explication en français.
Nous testons sur l’OWASP Top 10:2025, et fournissons sur demande la correspondance avec les catégories de 2021. Ces dix catégories constituent le socle de chaque pentest web ; le périmètre exact est arrêté au cadrage.
| Risque | Ce que cela recouvre |
|---|---|
| A01:2025 – Broken Access Control (contrôle d’accès défaillant) | Un utilisateur atteint des données ou des fonctions qui ne lui reviennent pas : dossier d’un autre client en modifiant un identifiant dans l’URL, écran d’administration appelé directement, droits élevés par manipulation d’un jeton. La révision 2025 y intègre le Server-Side Request Forgery (SSRF). C’est la catégorie qui produit le plus de constats critiques, et elle ne se teste qu’avec des comptes. |
| A02:2025 – Security Misconfiguration (configuration non sécurisée) | Serveurs, frameworks, conteneurs ou services managés laissés dans leur configuration d’origine : console d’administration exposée, compte de démonstration actif, en-têtes de sécurité absents, stockage ouvert. C’est ce qu’un attaquant opportuniste balaie en premier. |
| A03:2025 – Software Supply Chain Failures (défaillances de la chaîne d’approvisionnement logicielle) | Compromission de la chaîne logicielle : dépendances, chaînes de compilation, registres de paquets, canaux de mise à jour, et composants porteurs de vulnérabilités connues. Plus large que le « Vulnerable and Outdated Components » de 2021 qu’elle remplace. |
| A04:2025 – Cryptographic Failures (défaillances cryptographiques) | Erreurs de mise en œuvre de la cryptographie qui exposent des données sensibles : mots de passe stockés avec un algorithme obsolète, transport en clair sur un segment interne, clés en dur dans le dépôt, jetons signés avec un secret devinable. Dès que des données personnelles sont concernées, la question devient une question RGPD. |
| A05:2025 – Injection (injections) | L’application transmet à un interpréteur des données qu’elle n’a pas contrôlées, et l’attaquant les fait exécuter : injection SQL, injection de commandes système, injection dans un moteur de gabarits, cross-site scripting. Le résultat va de la lecture de la base à la prise de contrôle du serveur. |
| A06:2025 – Insecure Design (conception non sécurisée) | Un défaut de conception qu’aucun correctif ponctuel ne répare : réinitialisation de mot de passe sans limitation, règle métier contournable en changeant l’ordre des étapes, cloisonnement entre clients pensé après coup. La correction se joue au niveau de l’architecture. |
| A07:2025 – Authentication Failures (défaillances d’authentification) | Faiblesses de l’authentification, des identifiants et des sessions : énumération de comptes, absence de limitation des tentatives, second facteur contournable, session qui survit à la déconnexion. L’attaquant n’a alors besoin d’aucune vulnérabilité technique : il se connecte. |
| A08:2025 – Software or Data Integrity Failures (défaillances d’intégrité des logiciels ou des données) | Absence de vérification d’intégrité sur du code ou des données : mise à jour non signée, désérialisation d’un objet contrôlé par l’utilisateur, chaîne de déploiement qui accepte un artefact non vérifié. L’attaquant ne casse rien : il fait accepter son contenu. |
| A09:2025 – Security Logging and Alerting Failures (défaillances de journalisation et d’alerte) | Journalisation, alerte et supervision insuffisantes des événements de sécurité : l’attaque n’est pas vue pendant qu’elle se déroule et ne peut pas être reconstituée ensuite. Nos actions étant horodatées, nous comparons en fin de mission avec ce que vos journaux ont réellement enregistré. |
| A10:2025 – Mishandling of Exceptional Conditions (mauvaise gestion des conditions exceptionnelles) | Erreurs, exceptions et états imprévus mal traités : arrêt brutal du service, requête laissée passer en cas d’échec au lieu d’être refusée, traces d’exécution qui exposent la structure interne. Nouveauté de la révision 2025. |
Écosystème OWASP
Au-delà du Top 10 : les référentiels que nous utilisons
Dix catégories ne couvrent pas tout. Un test sérieux s’appuie sur les autres projets de la fondation, chacun répondant à une question différente : quoi vérifier, comment le vérifier, et sur quel type d’application.
OWASP API Security Top 10
Les risques propres aux interfaces de programmation, dont l’autorisation au niveau de l’objet et de la fonction. Derrière une API, le chemin vers vos données est plus court que par les écrans.
OWASP ZAP et Dependency-Check
L’outillage libre de la fondation, utilisé en appui : analyse dynamique et contrôle des bibliothèques tierces vulnérables. Tout résultat automatisé est vérifié à la main avant d’entrer dans le rapport.
Approches
Approches : boîte noire, boîte grise, boîte blanche
Un référentiel indique quoi tester ; l’approche détermine ce que vous pouvez réellement couvrir pour un nombre de jours donné. Dans la grande majorité des missions, nous recommandons la boîte grise : à budget égal, elle couvre davantage de surface, parce que nous ne passons pas la moitié des jours-homme à cartographier des parcours au lieu de chercher des vulnérabilités.
Boîte noire (black box)
Nous partons d’une adresse, sans compte ni documentation, comme un attaquant extérieur. L’approche mesure l’exposition publique. Sa limite est mécanique : une part du budget passe en reconnaissance et tout ce qui est derrière l’authentification reste hors de portée — la zone où se concentre la catégorie A01.
Boîte grise (grey box)
Nous disposons d’un compte par rôle et d’une description fonctionnelle. C’est l’approche par défaut : elle permet de comparer les rôles, de tester la logique métier et de vérifier qu’un client ne voit pas les données d’un autre — donc de couvrir le plus de catégories du Top 10 à nombre de jours égal.
Boîte blanche (white box)
Nous ajoutons le code source, la configuration et, si besoin, un accès à l’environnement. L’analyse gagne en profondeur sur les catégories difficiles à voir de l’extérieur : cryptographie, intégrité de la chaîne de construction, gestion des exceptions. À privilégier sur les applications critiques.
Notre méthodologie
Notre méthodologie et le déroulement d’une mission
Les référentiels OWASP disent quoi tester. La conduite de la mission, elle, suit le PTES (Penetration Testing Execution Standard) : cadrage, collecte de renseignement, modélisation des menaces, exploitation, post-exploitation et restitution. Tous nos tests sont réalisés sur mandat écrit, dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal).
Cadrage et mandat écrit
Une trentaine de minutes suffit à arrêter l’essentiel : applications et API concernées, rôles, environnement de test ou production, fenêtre d’intervention et approche retenue. Le nombre de jours-homme est ensuite fixé, écrit dans le devis et tenu. La note de cadrage et l’autorisation écrite précèdent toute action.
Reconnaissance et modélisation des menaces
Nous cartographions la surface réellement exposée — domaines, points d’entrée d’API, technologies, dépendances — puis nous écrivons le modèle de menaces propre à votre métier : une place de marché et un portail RH n’ont pas les mêmes abus.
Tests actifs : Top 10, WSTG, ASVS
Les cas de test proviennent du WSTG, complétés par l’ASVS au niveau convenu et par les scénarios de l’étape précédente ; chaque catégorie du Top 10 est parcourue. L’outillage couvre le volume, l’exploitation reste manuelle. Un constat critique ne vous attend pas dans le rapport : nous vous prévenons le jour même.
Rapport et restitution
Vous recevez un rapport en français : synthèse managériale, constats rattachés aux catégories OWASP, notation CVSS, étapes de reproduction et correction proposée. La restitution se tient en visioconférence avec vos équipes.
Contre-audit après correction
Une fois les correctifs déployés, nous revérifions les constats concernés et mettons le rapport à jour. Le contre-audit est inclus dans le prix, sans surcoût, dans les 90 jours suivant la remise du rapport.
Livrables : rapport, restitution et contre-audit
Vous n’achetez pas un fichier PDF, vous achetez de quoi décider et de quoi corriger. Un exemple de rapport anonymisé est disponible avant signature : vous savez exactement ce que vous recevrez.
Rapport technique en français
Chaque constat avec sa preuve d’exploitation, sa notation CVSS, la catégorie OWASP concernée et les étapes de reproduction.
Synthèse managériale
Deux à trois pages lisibles par un comité de direction : niveau de risque global, trois priorités et effort de remédiation estimé.
Restitution en visioconférence
Une séance animée par le pentesteur qui a conduit la mission, pas par un commercial — vos développeurs interrogent la personne qui a écrit le constat.
Contre-audit inclus
Revérification des constats corrigés et rapport mis à jour, sous 90 jours après la remise, sans facturation supplémentaire ni journée en option.
Ce que l’OWASP n’est pas
Il n’existe pas de « certification OWASP »
L’OWASP publie des documents ; elle ne délivre aucun certificat, ni à une entreprise ni à une application. Personne ne peut donc vous déclarer « conforme OWASP », et nous ne sommes pas un organisme de certification. Ce que nous produisons est un rapport d’audit technique, daté, qui dit ce qui a été testé et ce qui a été trouvé — le document que réclame un auditeur.
Ce n’est pas une norme, mais cela alimente les normes
Un test aligné sur l’OWASP ne remplace ni ISO/IEC 27001 ni PCI DSS ; il fournit la preuve technique que ces référentiels attendent. Pour la certification ISO/IEC 27001, les mesures de l’annexe A sur la sécurité du développement et les vulnérabilités techniques s’appuient sur ce type de test. Le RGPD, à l’article 32(1)(d), demande, lorsque c’est approprié, « une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles » : un test annuel suivi d’un contre-audit en est la traduction la plus courante. La directive (UE) 2022/2555 (NIS 2) impose, à son article 21, des mesures de gestion des risques sans exiger de test d’intrusion en tant que tel.
Ce n’est pas non plus un scan automatisé
Un scanner reconnaît des motifs connus : versions obsolètes, en-têtes manquants, injections triviales. Il ne comprend ni vos rôles, ni votre logique métier, ni la raison pour laquelle un utilisateur du service comptable ne devrait pas atteindre l’export des salaires — et les deux catégories où nous relevons le plus de constats critiques, A01 et A06, sont celles qu’aucun outil ne détecte seul. Nous avons traité la comparaison à part : scan de vulnérabilités ou test d’intrusion.
Dernière vérification : 11 septembre 2026.
Témoignages clients
Ce que nos clients disent de nous
Pourquoi Haxoris
Haxoris est un prestataire européen, établi dans l’Union européenne : vos données de test, vos rapports et les preuves d’exploitation restent dans l’UE, et le RGPD s’applique directement. Nous ne détenons aucune qualification délivrée par une autorité publique française et nous ne le prétendons pas. Ce que nous mettons à la place tient en trois points, vérifiables avant signature.
Contre-audit inclus, sans surcoût
La revérification de vos correctifs fait partie du prix, dans les 90 jours suivant la remise du rapport. Ni une journée facturée en supplément, ni une option de la proposition commerciale.
Nos tarifs sont publics
Les fourchettes en € HT et le tarif en jours-homme sont publiés, pas réservés à l’appel commercial. Le détail figure dans notre article sur le prix d’un test d’intrusion.
Vous savez qui teste
Vous connaissez avant la mission le nom du pentesteur affecté et ses certifications individuelles (OSCP, OSWE, OSEP). C’est lui qui rédige le rapport et anime la restitution.
Foire aux questions
01 Qu’est-ce que l’OWASP Top 10 ?
C’est la liste des dix risques de sécurité les plus sérieux pour les applications web, publiée par la fondation OWASP à partir de données remontées par des centaines d’organisations, puis révisée tous les trois à quatre ans. La version en vigueur est celle de 2025 : elle introduit deux catégories nouvelles, Software Supply Chain Failures et Mishandling of Exceptional Conditions.
02 L’OWASP Top 10 existe-t-il en français ?
Il n’existe pas de traduction française officielle de l’édition 2025 ; des traductions communautaires couvrent les éditions antérieures. Le tableau ci-dessus donne, pour chaque catégorie, l’intitulé anglais, sa traduction et une explication en français. Nous conservons l’intitulé anglais dans les rapports : c’est celui qui circulera dans vos tickets et dans vos réponses aux questionnaires de sécurité.
03 Combien coûte un test d’intrusion aligné sur l’OWASP ?
Le prix suit le périmètre : nombre d’applications, de rôles et de points d’entrée d’API, intégrations, et accès ou non au code source. Un test d’application web démarre à 2 000 € HT ; une mission courante représente 5 à 15 jours-homme. Nos tarifs sont publics : le détail figure dans notre article sur le prix d’un test d’intrusion. Après le cadrage, vous recevez un devis ferme, sans engagement.
04 Combien de jours-homme faut-il prévoir ?
Parcourir les dix catégories du Top 10 sur une application à deux rôles et une quinzaine de points d’entrée demande 5 à 8 jours-homme. Ajouter l’ASVS au niveau L2, une API GraphQL et des intégrations tierces porte la mission à 10 à 20 jours-homme. Le chiffre est arrêté au cadrage et inscrit dans le devis ; s’il s’avère insuffisant, nous vous le disons avant de consommer le budget, pas après.
05 Boîte noire ou boîte grise ?
La boîte grise dans la grande majorité des cas. La catégorie A01, contrôle d’accès défaillant, produit le plus de constats critiques et n’est testable qu’avec des comptes : sans un compte par rôle, une part importante du Top 10 reste hors de portée. La boîte noire garde son intérêt pour mesurer l’exposition d’une application publique ; la boîte blanche s’impose sur les applications critiques.
06 Le contre-audit est-il inclus ?
Oui, dans le prix et sans surcoût. Après vos corrections, nous revérifions les constats concernés et mettons le rapport à jour, dans les 90 jours suivant sa remise. Vous obtenez la version du rapport qui montre l’état après correction — celle que réclament vos clients grands comptes et vos auditeurs.
07 Faut-il faire appel à un prestataire qualifié ?
Pas pour un test commandé par une entreprise privée. La qualification délivrée par l’ANSSI au titre du décret n° 2015-350 du 27 mars 2015 relève d’une démarche volontaire ; elle n’est pas exigée pour faire tester une application d’entreprise. Haxoris ne détient aucune qualification délivrée par l’ANSSI. En revanche, les contrôles des systèmes d’information d’importance vitale ordonnés au titre de l’article L. 1332-6-3 du code de la défense sont réalisés par l’ANSSI, par des services de l’État désignés par le Premier ministre, ou par des prestataires de service qualifiés : nous ne soumissionnons pas sur ces prestations. Nous détaillons ce point dans un article dédié : faut-il un prestataire qualifié pour un test d’intrusion ?
