OWASP Top 10 en langage clair —
les 10 risques web qu'une PME québécoise doit connaître

Comprendre l'OWASP Top 10 — guide pratique pour les PME québécoises

L'OWASP Top 10 n'est pas un cadre obligatoire au sens légal, mais c'est la grille de référence universelle qu'utilisent les développeurs, les auditeurs et les contrôles qualité partout dans le monde. Comprendre ses 10 catégories permet à une PME de mieux dialoguer avec son équipe TI, son hébergeur ou un consultant — et de cibler les vrais risques sur son site.

Préalable conseillé : avant d'aborder cette page, parcourir la Formation Site web et Loi 25 qui couvre les obligations Loi 25 pour le site (politique, consentement cookies, formulaires). La présente fiche complète sur la dimension sécurité technique.

Qu'est-ce que l'OWASP Top 10 et pourquoi c'est central

L'OWASP est une fondation à but non lucratif qui produit des outils et des standards de sécurité applicative en accès libre. Le Top 10 est leur publication la plus connue — utilisée comme référence par des milliers d'organisations, intégrée dans les standards (PCI DSS, ISO 27001), citée dans les appels d'offres, et reprise par les contrôles qualité de site web.

Pourquoi cette référence est centrale pour une PME :

• Universellement comprise — un développeur, un consultant ou un auditeur partout dans le monde sait ce qu'est « A01:2021 Broken Access Control ». La référence évite les ambigüités.
• Pertinente pour les sites de PME — les vulnérabilités du Top 10 touchent tous les sites web, peu importe la taille. Le formulaire de contact d'un entrepreneur électricien a les mêmes vecteurs d'attaque qu'une plateforme commerciale.
• Alignée avec la Loi 25 — l'article 10 de la Loi 25 exige des « mesures de sécurité raisonnables ». L'OWASP Top 10 est l'un des cadres reconnus pour démontrer cette diligence raisonnable côté web.
• Actionnable — chaque catégorie correspond à des vérifications concrètes. Un contrôle qualité peut indiquer « Risque A05:2021 Security Misconfiguration » plutôt qu'un vague « problème de configuration ».

Les 5 premières catégories — les plus critiques

A01:2021 — Broken Access Control (Contrôle d'accès défaillant)

La catégorie la plus fréquente. Elle survient quand un utilisateur peut accéder à des ressources qui ne devraient pas lui être accessibles : voir le profil d'un autre client, modifier des données qui ne lui appartiennent pas, accéder à des fonctionnalités d'administration. Pour une PME, le cas typique : un site avec espace client où l'URL contient l'identifiant du client (`/dossier?id=123`) — changer l'identifiant donne accès au dossier d'un autre client. C'est aussi cette catégorie qui couvre l'énumération d'utilisateurs WordPress via `?author=N`.

A02:2021 — Cryptographic Failures (Défaillances cryptographiques)

Anciennement « Sensitive Data Exposure ». Couvre tout ce qui touche à la protection des données en transit et au repos : HTTPS mal configuré, certificats expirés, mots de passe stockés en clair, données sensibles transmises sans chiffrement. Pour une PME, c'est le SSL/TLS de son site, le chiffrement des bases de données client, la sécurité des sauvegardes. Une note SSL Labs grade A+ couvre largement la dimension transport.

A03:2021 — Injection

Inclut les injections SQL, les injections de commandes système, et le Cross-Site Scripting (XSS, anciennement catégorie distincte). L'attaquant injecte du code malveillant via un formulaire ou un paramètre URL. Pour une PME, le cas typique : un formulaire de contact qui ne valide pas les entrées et qui exécute du code injecté. Les plateformes modernes (WordPress avec plugins à jour, Wix, Shopify) gèrent l'essentiel — mais des plugins obsolètes ou des thèmes maison non maintenus restent vulnérables.

A04:2021 — Insecure Design (Conception non sécuritaire)

Nouvelle catégorie en 2021. Couvre les défauts de conception qui ne peuvent pas être corrigés par configuration — il faut repenser l'architecture. Pour une PME, c'est rarement une préoccupation directe (on n'écrit pas son CMS), sauf pour les développements sur mesure. Le réflexe : poser la question « la sécurité a-t-elle été considérée dès la conception? » avant de signer un devis de développement web.

A05:2021 — Security Misconfiguration (Mauvaise configuration de sécurité)

L'une des plus fréquentes pour les sites de PME. En-têtes HTTP de sécurité absents (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), fichiers sensibles laissés accessibles (`/.env`, `/wp-config.php.bak`, `/.git/`), comptes par défaut non désactivés, version du CMS exposée. C'est précisément la catégorie qu'un contrôle qualité de site web vérifie de façon systématique.

Les 5 catégories suivantes — à ne pas négliger

A06:2021 — Vulnerable and Outdated Components (Composants vulnérables et obsolètes)

Très pertinent pour les sites WordPress, Drupal, Joomla. Quand un plugin ou un thème n'est plus maintenu, ou qu'il existe une CVE publique non corrigée, le site devient vulnérable. Pour une PME : appliquer les mises à jour, retirer les plugins inutilisés, vérifier que les plugins actifs ont une version récente. La cross-référence avec la base CVE (via WPScan pour WordPress, par exemple) est l'outil de diagnostic.

A07:2021 — Identification and Authentication Failures

Anciennement « Broken Authentication ». Couvre les mots de passe faibles, l'absence de 2FA/MFA, les sessions mal gérées, les comptes administrateur avec des noms triviaux (`admin`, `root`). Pour une PME : activer le MFA sur les comptes administrateur du CMS, renommer les comptes par défaut, limiter les tentatives de connexion. C'est l'une des dimensions les plus simples à corriger avec le plus d'impact.

A08:2021 — Software and Data Integrity Failures

Nouvelle catégorie en 2021. Couvre les chaînes d'approvisionnement logicielles compromises, les mises à jour non vérifiées, les pipelines CI/CD non sécurisés. Pour une PME, c'est rarement un risque direct sauf si elle développe sa propre application. Le réflexe : ne télécharger les plugins que depuis le répertoire officiel de la plateforme, vérifier les sources des thèmes.

A09:2021 — Security Logging and Monitoring Failures

Quand un incident survient, les journaux permettent de comprendre ce qui s'est passé. Sans journalisation, l'organisation ne sait pas qu'elle a été attaquée — ou elle l'apprend trop tard. Pour une PME : activer les journaux d'accès (la plupart des hébergeurs les conservent par défaut), surveiller les tentatives de connexion répétées sur l'admin, conserver les logs pour la durée de la prescription de la Loi 25.

A10:2021 — Server-Side Request Forgery (SSRF)

Catégorie technique : un attaquant force le serveur à faire des requêtes vers des destinations qu'il choisit, contournant les contrôles d'accès réseau. Pour une PME, c'est rarement un risque direct sauf pour les développements sur mesure ou les intégrations API complexes. Le réflexe : si votre site fait des appels à des API externes, vérifier avec votre développeur que les URLs sont validées côté serveur.

Articulation avec la Loi 25 et les contrôles qualité

Pour une PME québécoise, la traduction concrète :

• Quand la CAI examine une plainte ou un incident, elle vérifie si l'organisation avait pris des mesures de sécurité raisonnables. Pouvoir démontrer une couverture des principales catégories OWASP est un argument fort.
• Quand un donneur d'ouvrage exige une attestation de sécurité (appels d'offres publics ou contrats avec institutions), l'OWASP Top 10 est souvent cité comme référence minimale.
• Quand un contrôle qualité de site web est livré, ses critères de sécurité font typiquement référence à OWASP — chaque vulnérabilité identifiée est rattachée à une catégorie du Top 10.
• Quand un assureur cyber évalue le risque, il regarde la maturité OWASP avant de proposer une prime ou des conditions.

Concrètement, dans les contrôles qualité de site web, voici les correspondances typiques entre les vérifications et les catégories OWASP :

• HTTPS et certificat TLS valide → A02:2021 Cryptographic Failures
• HSTS et en-têtes de sécurité (CSP, X-Frame-Options, Referrer-Policy) → A05:2021 Security Misconfiguration
• Fichiers sensibles non exposés (`.env`, `.git`, sauvegardes) → A05:2021 Security Misconfiguration
• Version du CMS masquée → A05:2021 Security Misconfiguration et A06:2021 Vulnerable Components
• Pas d'énumération d'utilisateurs (WordPress `?author=N`) → A01:2021 Broken Access Control
• API REST contrôlée (pas de fuite de renseignements via `/wp-json/`) → A01:2021 Broken Access Control
• Page de connexion durcie, MFA, limitation des tentatives → A07:2021 Authentication Failures

Comment une PME exploite l'OWASP Top 10 sans devenir experte en cybersécurité

Démarche recommandée pour une PME québécoise :

1. Faire un contrôle qualité initial — automatisé (Mozilla Observatory pour les en-têtes, SSL Labs pour le TLS) puis manuel (vérification des fichiers sensibles, des comptes par défaut, des plugins obsolètes). Le résultat se lit avec la grille OWASP.
2. Corriger les écarts les plus critiques — typiquement A01, A02, A05 et A07 dans l'ordre. La majorité se règle par configuration, pas par développement.
3. Mettre en place un calendrier de revue — vérification trimestrielle des plugins et thèmes (A06), revue annuelle des contrôles d'accès (A01) et des configurations (A05), revue des journaux mensuelle (A09).
4. Former les administrateurs du site — la majorité des incidents viennent d'un compte administrateur compromis (A07). Un mot de passe fort, le MFA et la prudence sur les liens suspects couvrent l'essentiel.
5. Documenter les mesures en place — pour pouvoir démontrer la diligence raisonnable en cas de plainte ou d'incident, l'organisation doit pouvoir produire la liste des mesures qu'elle a prises et leur date de mise en œuvre.

Pour une PME qui n'a pas d'équipe TI interne, l'option courante est de faire faire un contrôle qualité de site web par un consultant ou un développeur familier avec OWASP — et de répéter cet exercice tous les 12 à 18 mois.

Erreurs fréquentes et pièges à éviter

• ❌ Penser que « petit site = pas de cible » — les attaques sont automatisées. Un robot qui scanne 10 000 sites par heure ne sait pas que le vôtre est une PME de 4 employés. Si une vulnérabilité OWASP est présente, elle sera exploitée tôt ou tard.
• ❌ Plugins WordPress installés et oubliés — la plus grande source d'incidents WordPress vient de plugins non mis à jour ou abandonnés par leur auteur. Un plugin avec une CVE active est une porte ouverte (catégorie A06).
• ❌ Compte administrateur nommé « admin » ou « root » — combiné avec l'énumération d'utilisateurs (A01), cela donne à un attaquant un identifiant valide à tester. Renommer le compte est un geste de 2 minutes qui retire un vecteur entier.
• ❌ HTTPS partiel — site principal en HTTPS mais certaines ressources (images, scripts) chargées en HTTP. Le navigateur peut afficher un cadenas brisé. Couvre la catégorie A02.
• ❌ Pas de journalisation activée — quand un incident survient, l'organisation découvre qu'elle n'a aucune trace de ce qui s'est passé. Catégorie A09. La majorité des hébergeurs offrent les journaux d'accès — il suffit souvent de les activer.
• ❌ Pas de MFA sur les comptes administrateur — un mot de passe seul ne suffit plus. Les attaques par dictionnaire et par credential stuffing (réutilisation de mots de passe fuités ailleurs) sont automatisées. Catégorie A07.
• ❌ Confondre conformité et sécurité — une politique de confidentialité conforme à la Loi 25 ne protège pas le site contre une vulnérabilité OWASP. Les deux dimensions sont nécessaires et complémentaires.

L'erreur de raisonnement la plus fréquente : « si le site fonctionne, c'est qu'il est sécurisé ». La sécurité web ne se voit pas — un site peut fonctionner parfaitement tout en exposant ses utilisateurs à des risques majeurs. Seul un contrôle qualité structuré révèle ce qui est invisible à l'œil nu.