Une boutique en ligne de Québec qui vend des produits du terroir. Un courtier d'assurance de Longueuil dont les clients téléversent leurs relevés bancaires dans un portail. Une coopérative agricole qui permet à ses membres de consulter leurs livraisons en ligne. Trois PME, un point commun : leur application web est devenue leur porte d'entrée principale.
Et cette porte est ouverte 24 heures sur 24, à tout Internet. Les pare-feu et les antivirus protègent vos postes et vos serveurs, mais ils ne voient pas qu'un client peut afficher le dossier d'un autre client en changeant un chiffre dans l'adresse.
C'est le rôle du test d'intrusion d'application web. Et pour en parler, tout le monde utilise la même référence : l'OWASP Top 10, dont l'édition 2025 est la plus récente.
En bref
- Un test d'intrusion web vérifie ce qu'un attaquant peut faire dans votre application : voler des comptes, accéder aux données des autres clients, détourner un paiement.
- L'OWASP Top 10 2025 liste les dix grandes catégories de risques; le contrôle d'accès défaillant reste au premier rang.
- Le Top 10 est un plancher, pas un plafond : un bon test couvre aussi la logique d'affaires propre à votre application.
- Côté prix, les fournisseurs canadiens publient des fourchettes très larges, de quelques milliers à plusieurs dizaines de milliers de dollars selon la portée.
Ce qu'un test d'intrusion web vérifie
Le testeur se met à la place de plusieurs types d'utilisateurs : un visiteur anonyme, un client connecté, un employé, un administrateur. Pour chacun, il pose la même question : que puis-je faire que je ne devrais pas pouvoir faire ?
Concrètement, il examine l'authentification (connexion, réinitialisation du mot de passe, sessions), les autorisations entre comptes, les formulaires et les téléversements de fichiers, les API utilisées par votre application mobile ou vos partenaires, et la configuration du serveur.
La plupart des tests web se font en boîte grise : vous fournissez des comptes de test pour chaque rôle. C'est plus efficace qu'une approche à l'aveugle, puisque les failles les plus graves se trouvent généralement derrière l'écran de connexion. Comme tout test d'intrusion, il exige une autorisation écrite (Code criminel, art. 342.1) et, si votre application est hébergée chez un tiers, le respect de ses conditions.
L'OWASP Top 10 2025, en clair
L'OWASP est une fondation sans but lucratif qui publie des ressources ouvertes sur la sécurité des applications. Son Top 10 est un document de sensibilisation, mis à jour périodiquement à partir de données réelles et d'un sondage auprès de la communauté. L'édition 2025 est la huitième. Elle introduit deux nouvelles catégories (chaîne d'approvisionnement logicielle et gestion des conditions exceptionnelles) et intègre la falsification de requêtes côté serveur (SSRF) au contrôle d'accès.
Les noms officiels sont en anglais. Voici ce qu'ils veulent dire pour une PME :
| # | Catégorie OWASP 2025 | Exemple concret |
|---|---|---|
| A01 | Broken Access Control (contrôle d'accès défaillant) | Un client consulte la facture d'un autre en modifiant le numéro dans l'URL |
| A02 | Security Misconfiguration (mauvaise configuration) | Page d'administration accessible depuis Internet, stockage infonuagique public |
| A03 | Software Supply Chain Failures (chaîne d'approvisionnement) | Extension WordPress abandonnée, bibliothèque JavaScript compromise |
| A04 | Cryptographic Failures (défaillances cryptographiques) | Mots de passe mal protégés en base de données, chiffrement désuet |
| A05 | Injection | Champ de recherche qui permet d'interroger directement la base de données |
| A06 | Insecure Design (conception non sécurisée) | Code promo utilisable à l'infini, aucune limite de tentatives |
| A07 | Authentication Failures (authentification) | Aucun MFA pour les administrateurs, sessions qui n'expirent jamais |
| A08 | Software or Data Integrity Failures (intégrité) | Mises à jour ou données acceptées sans vérifier leur provenance |
| A09 | Security Logging & Alerting Failures (journalisation et alertes) | Des milliers de tentatives de connexion, et personne n'est averti |
| A10 | Mishandling of Exceptional Conditions (conditions exceptionnelles) | Une erreur affiche le détail technique du serveur, ou un paiement échoue « ouvert » |
Ce n'est pas un hasard si le contrôle d'accès défaillant occupe le premier rang depuis l'édition 2021 : c'est une faille répandue, difficile à détecter avec des outils automatisés, et l'une des plus graves quand des renseignements personnels sont en jeu.
Au-delà du Top 10 : la logique d'affaires
Un fournisseur qui promet de « tester l'OWASP Top 10 » ne vous dit pas grand-chose. Les failles les plus coûteuses sont souvent propres à votre application : commander une quantité négative pour obtenir un crédit, sauter l'étape de paiement en rappelant directement la page de confirmation, approuver sa propre demande de remboursement.
Aucun scanner ne trouve ce genre de problème. Il faut quelqu'un qui comprend votre processus d'affaires. C'est pourquoi les testeurs sérieux s'appuient sur une méthodologie complète, comme le Web Security Testing Guide (WSTG) de l'OWASP, et utilisent le Top 10 comme liste minimale. Si vous hésitez entre un scan et un vrai test, notre article sur les différences entre audit, pentest et scan vous aidera à trancher.
Comment se déroule le test
- Cadrage : liste des URL, des rôles, des API et des exclusions, choix de l'environnement et signature de l'autorisation.
- Reconnaissance : cartographie de l'application, des technologies et des composants tiers utilisés.
- Tests manuels et automatisés : chaque catégorie du Top 10, puis la logique d'affaires, rôle par rôle.
- Alerte immédiate en cas de faille critique : le testeur vous avertit sans attendre le rapport, pour que vous puissiez corriger tout de suite.
- Rapport et présentation, puis retest une fois les corrections déployées.
Selon la taille de l'application, la phase de tests dure de quelques jours à quelques semaines. Prévoyez que vos développeurs soient disponibles pour répondre aux questions, surtout les premiers jours.
Préparer votre application au test
Une bonne préparation permet aux testeurs de consacrer leur temps aux failles plutôt qu'aux problèmes d'accès. Avant le démarrage :
- Un environnement de préproduction aussi proche que possible de la production
- Au moins deux comptes de test par rôle, pour vérifier qu'un client ne voit pas les données d'un autre
- Des données fictives, jamais de vrais renseignements personnels de clients
- Une autorisation écrite signée par une personne habilitée, et l'accord de l'hébergeur si requis
- La liste des fonctions critiques : paiement, téléversement, réinitialisation de mot de passe, exportations
- La documentation des API, s'il y en a
- Un contact technique joignable pendant toute la durée du test
- Une sauvegarde récente de l'environnement testé
- Un gel des déploiements majeurs pendant la fenêtre de test
Budget, rapport et retest
Les fournisseurs canadiens publient des fourchettes très larges pour les tests d'intrusion, de quelques milliers à plusieurs dizaines de milliers de dollars selon la portée (par exemple, Packetlabs, août 2026). Pour une application web, le nombre de rôles, de fonctionnalités et de points d'API fait varier le prix, tout comme l'inclusion d'un retest. Ce sont des repères indicatifs; nous détaillons les autres facteurs dans notre article sur le prix d'un test d'intrusion.
Le rapport classe chaque faille selon sa gravité, avec les étapes pour la reproduire et une recommandation de correction pour vos développeurs. Notre guide pour lire un rapport de test d'intrusion explique comment le transformer en plan de travail.
Un dernier point, propre au Québec : la Loi 25 exige une évaluation des facteurs relatifs à la vie privée (EFVP) pour tout projet d'acquisition, de développement ou de refonte d'un système d'information qui implique des renseignements personnels (art. 3.3). Un nouveau portail client entre dans cette catégorie, et un test d'intrusion est une pièce utile pour documenter les mesures de sécurité dans votre EFVP. Validez la portée de vos obligations avec votre conseiller juridique.
Notre équipe réalise des tests d'intrusion d'applications web en boîte grise, avec une couverture complète de l'OWASP Top 10 et de la logique d'affaires de votre application.
Questions fréquentes
Faut-il tester l'application en production ou en préproduction ?+
Idéalement dans un environnement de préproduction identique à la production, pour éviter tout impact sur vos clients et vos données réelles. Certains éléments, comme la configuration du serveur ou du pare-feu applicatif, doivent toutefois être vérifiés en production, avec des précautions convenues d'avance.
Notre site Shopify ou WordPress a-t-il besoin d'un test d'intrusion ?+
Sur une plateforme hébergée comme Shopify, la plateforme elle-même est sécurisée par le fournisseur; votre risque se situe dans les applications ajoutées, les comptes administrateurs et les intégrations. Un site vitrine WordPress sans fonctionnalités sur mesure se contente souvent d'un durcissement et d'un scan régulier. Le test d'intrusion devient pertinent dès qu'il y a des comptes clients, des paiements ou des développements sur mesure.
Existe-t-il une certification « conforme OWASP » ?+
Non. L'OWASP ne certifie ni les applications ni les fournisseurs. Le Top 10 est un document de sensibilisation; pour des exigences vérifiables, l'OWASP publie l'ASVS (Application Security Verification Standard), qui propose trois niveaux d'exigence selon la sensibilité de l'application.
Sources
- 1.OWASP Top 10:2025
- 2.OWASP Web Security Testing Guide (WSTG)
- 3.OWASP Application Security Verification Standard (ASVS)
- 4.Packetlabs : coût moyen d'un test d'intrusion au Canada (août 2026)
- 5.Code criminel, art. 342.1 : utilisation non autorisée d'ordinateur
- 6.Loi sur la protection des renseignements personnels dans le secteur privé (RLRQ c. P-39.1)