Sécurité d'un site ou d'une application : les 10 risques OWASP expliqués à un dirigeant

Sécurité d'un site ou d'une application : les 10 risques OWASP expliqués à un dirigeant

Vous n'avez pas à comprendre le code pour poser les bonnes questions. Vous avez à obtenir des réponses précises, ou à constater qu'il n'y en a pas.

Réponse courte. L'OWASP publie une liste de dix catégories de risques pour les applications web. L'édition lue sur le site officiel le 8 novembre 2026 porte le millésime 2025. Elle sert de grille de discussion, pas de certificat. Cet article reprend les dix catégories dans l'ordre publié, explique chacune en langage courant et propose pour chacune une question à poser à votre prestataire. Une bonne réponse est concrète (on a testé ceci, on conserve cela) ; une mauvaise réponse est un slogan.

Transparence. BOVO Digital est une agence basée à Abomey-Calavi (Bénin) qui réalise des sites, des applications et des SaaS : nous vendons ce type de prestation, donc nous avons un intérêt dans ce sujet. Cet article ne repose sur aucun projet, aucun client, aucun prix et aucun résultat de BOVO. Il lit la page officielle du Top 10 de l'OWASP, celle de l'ASVS, une fiche pratique de l'OWASP, la documentation de Next.js et celle de Stripe, le 8 novembre 2026. Nous n'avons réalisé aucun test d'intrusion pour cet article et nous ne citons aucune statistique d'incidents.

Ce qu'est le Top 10 de l'OWASP, et ce qu'il n'est pas

L'OWASP est une fondation qui publie des ressources ouvertes sur la sécurité des applications. Son Top 10 est une liste de catégories de risques, pas une liste de failles précises. La page que nous avons lue porte la mention « 2025 » et dit que cette version intègre les dernières données et tendances de sécurité. Elle ne donne ni date de publication ni description de la base de données utilisée : nous ne les citons donc pas. L'adresse owasp.org/Top10/2025 redirige vers top10.owasp.org/2025.

Deux précisions utiles pour un dirigeant :

• Ce n'est pas un label. Dire « notre site respecte l'OWASP Top 10 » ne signifie rien de vérifiable en soi. La bonne question est « quelles mesures avez-vous prises pour chaque catégorie, et comment les avez-vous testées ? ».
• Il existe un document plus exigeant pour un contrat. L'ASVS (Application Security Verification Standard) est présenté par l'OWASP comme un cadre d'exigences pour concevoir, développer et tester des applications web. Sa dernière version stable affichée est la 5.0.0, publiée le 30 mai 2025. On peut s'en servir pour écrire ce que l'on attend du prestataire. Nous n'avons pas lu ses niveaux en détail.

Si vous avez déjà lu notre article plus ancien sur le Top 10 2025, celui-ci en est un complément à destination des décideurs : moins de détails techniques, plus de questions à poser.

Les dix catégories, lues sur la page officielle

La liste ci-dessous reprend les intitulés tels que publiés sur top10.owasp.org/2025, en anglais. La traduction qui suit chaque intitulé est la nôtre.

1. A01 Broken Access Control (contrôle d'accès défaillant)
2. A02 Security Misconfiguration (mauvaise configuration de sécurité)
3. A03 Software Supply Chain Failures (défaillances de la chaîne d'approvisionnement logicielle)
4. A04 Cryptographic Failures (défaillances cryptographiques)
5. A05 Injection
6. A06 Insecure Design (conception non sécurisée)
7. A07 Authentication Failures (défaillances d'authentification)
8. A08 Software or Data Integrity Failures (défaillances d'intégrité des logiciels ou des données)
9. A09 Security Logging and Alerting Failures (défaillances de journalisation et d'alerte)
10. A10 Mishandling of Exceptional Conditions (mauvaise gestion des conditions exceptionnelles)

Nous ne reprenons pas ici le classement chiffré ni les évolutions par rapport à l'édition précédente : la page lue ne les détaille pas assez pour que nous les affirmions.

A01, contrôle d'accès : « qui a le droit de voir ou de modifier quoi ? »

En clair. Un utilisateur connecté ne doit voir que ses propres données et n'effectuer que les actions qui lui sont permises. Le risque est qu'un client puisse lire la facture d'un autre en changeant un numéro dans l'adresse, ou qu'un simple utilisateur accède à une fonction d'administration.

Ce que disent les sources. La fiche OWASP sur l'autorisation pose trois principes : refuser par défaut, accorder le minimum de droits nécessaires, et vérifier les permissions à chaque requête, côté serveur, car les contrôles côté navigateur se contournent facilement. La documentation de Next.js précise que les « Server Actions » (les fonctions appelées par les formulaires) restent joignables par une requête directe, et qu'il faut y revérifier l'identité et le droit sur la ressource concernée, pas seulement sur la page qui les affiche.

Question à poser. « Où, dans le code, vérifiez-vous qu'un utilisateur a le droit d'accéder à cet enregistrement précis, et avez-vous écrit un test où l'utilisateur A tente de lire ou modifier les données de l'utilisateur B ? »

A02, configuration : « qu'est-ce qui est resté ouvert ? »

En clair. Un logiciel bien écrit peut être mal réglé : accès d'administration exposé, mots de passe par défaut, messages d'erreur trop bavards, secrets publiés par erreur.

Ce que disent les sources. Next.js indique que, par défaut, les variables d'environnement ne sont disponibles que côté serveur, et que toute variable préfixée NEXT_PUBLIC_ est exposée au navigateur. Un secret placé sous ce préfixe est donc public.

Question à poser. « Quelles clés ou quels secrets se trouvent dans l'application, où sont-ils stockés, et comment vérifiez-vous qu'aucun n'est exposé au navigateur ? »

A03, chaîne d'approvisionnement : « de quoi votre site est-il fait ? »

En clair. Un site moderne assemble des centaines de composants écrits par des tiers. Si l'un d'eux est compromis ou contient une faille connue, votre site l'est aussi. C'est une catégorie intitulée « Software Supply Chain Failures » sur la page officielle.

Ce que nous avons lu et ce que nous n'avons pas lu. Nous avons raconté dans un autre article une version de sécurité de Next.js corrigeant neuf failles : cela illustre qu'il faut suivre les mises à jour, sans que nous en tirions une fréquence moyenne. Nous n'avons pas lu de guide d'agence nationale sur ce point pour cet article.

Question à poser. « Qui surveille les failles publiées sur les composants que vous utilisez, et sous quel délai appliquez-vous une mise à jour de sécurité ? Que se passe-t-il après la livraison : est-ce prévu au contrat ? »

A04, cryptographie : « les données sensibles sont-elles protégées en route et au repos ? »

En clair. Les données qui circulent (connexion, formulaire, paiement) doivent être chiffrées, et celles qui sont stockées (mots de passe, pièces d'identité) ne doivent jamais l'être en clair. Les mots de passe, en particulier, ne se conservent pas tels quels.

Question à poser. « Comment stockez-vous les mots de passe, quelles données personnelles conservez-vous, lesquelles sont chiffrées, et pourquoi conservez-vous celles-ci plutôt que de ne pas les collecter ? » Pour le cadre légal des données en Afrique de l'Ouest, voir notre article sur la protection des données.

A05, injection : « que se passe-t-il si quelqu'un tape du code dans un formulaire ? »

En clair. Si une application insère telle quelle dans une requête ce qu'un visiteur a saisi, elle peut exécuter des instructions qu'il a glissées. Les défenses courantes consistent à valider les entrées et à utiliser des requêtes paramétrées.

Ce que disent les sources. Next.js demande de toujours valider ce qui vient du client (formulaires, paramètres d'adresse, en-têtes), parce que tout cela peut être modifié, et son exemple de code utilise une requête avec valeurs séparées plutôt qu'un texte concaténé.

Question à poser. « Comment validez-vous les saisies, et utilisez-vous partout des requêtes paramétrées ou une couche d'accès aux données qui le fait ? »

A06, conception : « la sécurité a-t-elle été pensée avant d'écrire le code ? »

En clair. Certains problèmes ne sont pas des erreurs de code mais des erreurs de conception : un parcours de réinitialisation de mot de passe trop permissif, un tarif calculé côté navigateur, aucune limite sur les envois d'e-mails. Aucun correctif ne les rattrape, il faut repenser la fonction.

Ce que disent les sources. Next.js recommande, pour les nouveaux projets, une couche d'accès aux données dédiée qui ne s'exécute que côté serveur, vérifie les autorisations et ne renvoie que le strict nécessaire. Il suggère aussi une limitation de débit pour les opérations coûteuses comme l'envoi d'e-mails.

Question à poser. « Avez-vous listé, avant le développement, les abus possibles de chaque fonction (compte volé, envoi massif, prix manipulé), et qu'avez-vous prévu contre chacun ? »

A07, authentification : « comment prouve-t-on qui est connecté ? »

En clair. La connexion est la porte d'entrée. Les défaillances typiques : mots de passe faibles acceptés, sessions qui ne se ferment jamais, récupération de compte contournable.

Question à poser. « Utilisez-vous une solution d'authentification éprouvée plutôt qu'un système maison ? Quelle est la durée de vie d'une session, et peut-on activer une double authentification pour les comptes d'administration ? » Nous n'avons pas lu dans cet article de référence détaillée sur l'authentification : ces points sont des questions, pas des exigences chiffrées.

A08, intégrité : « peut-on croire ce qui arrive à votre application ? »

En clair. Une application qui reçoit des messages d'un autre service, par exemple une confirmation de paiement, doit s'assurer que le message vient bien de ce service et n'a pas été falsifié. Sinon, n'importe qui peut envoyer un faux « paiement reçu ».

Ce que disent les sources. La documentation de Stripe sur les webhooks écrit que, sans vérification, un attaquant pourrait envoyer de faux événements pour déclencher des actions comme l'exécution de commandes ou l'accès à un compte. Elle demande de vérifier la signature portée par l'en-tête Stripe-Signature avec le secret du point d'accès, de conserver le corps brut de la requête (toute modification fait échouer la vérification), et de rejeter les signatures trop anciennes (tolérance par défaut de cinq minutes dans les bibliothèques officielles). Elle recommande aussi de journaliser les identifiants d'événements traités pour ignorer les doublons, et de changer périodiquement le secret. Pour la mise en œuvre dans un SaaS, voir notre article sur Next.js, Stripe et les webhooks et les erreurs courantes de webhooks Mobile Money.

Question à poser. « Comment vérifiez-vous que les confirmations de paiement viennent bien du prestataire de paiement, et que se passe-t-il si la même confirmation arrive deux fois ? »

A09, journalisation et alerte : « saurez-vous qu'il s'est passé quelque chose ? »

En clair. Sans traces, un incident passe inaperçu pendant des semaines, et on ne peut ni l'expliquer ni le corriger. Il faut des journaux utiles (connexions, échecs, actions sensibles) et quelqu'un qui reçoit une alerte.

Question à poser. « Quels événements journalisez-vous, pendant combien de temps, qui reçoit l'alerte en cas d'anomalie, et ces journaux contiennent-ils des données personnelles ou des secrets ? » Nous n'avons pas de chiffre de référence sur la durée de détection et nous n'en donnons pas.

A10, conditions exceptionnelles : « que fait l'application quand ça se passe mal ? »

En clair. Panne du service de paiement, réponse incomplète, saisie inattendue : l'application doit échouer proprement, sans afficher de détails internes et sans laisser une opération à moitié faite (client débité, commande non créée).

Question à poser. « Que voit l'utilisateur quand le paiement échoue ou que le serveur ne répond pas, et comment rattrapez-vous une opération interrompue au milieu ? » C'est la catégorie dont l'intitulé est le plus récent à nos yeux ; nous n'avons pas comparé avec l'édition précédente.

Avant, pendant et après : quelles preuves demander

Les questions ci-dessus se résument en quatre demandes de preuve :

1. Un document de conception qui nomme les données sensibles, les rôles d'utilisateurs et les abus envisagés.
2. Des tests écrits pour les contrôles d'accès et les confirmations de paiement, que vous pouvez voir exécuter.
3. La liste des composants utilisés et la personne responsable des mises à jour, avec une réponse claire sur la période après livraison.
4. Un plan d'incident : qui est prévenu, qui coupe l'accès, comment on restaure une sauvegarde (et si elle a déjà été restaurée au moins une fois pour vérifier qu'elle fonctionne).

La documentation de Next.js propose en outre une liste de points à regarder lors d'un audit : la couche d'accès aux données, les fichiers use client et use server, les paramètres d'adresse et les fichiers proxy.ts et route.ts, qui ont « beaucoup de pouvoir ». Vous pouvez la montrer à un auditeur indépendant. Pour la propriété du code et des accès, voir aussi qui possède le code.

Ce que nous ne savons pas

• La date de publication exacte et la base de données de l'édition 2025 du Top 10 : la page lue ne les donne pas.
• Le contenu détaillé de chaque catégorie : nous avons lu la liste des intitulés, pas les pages de chaque catégorie. Les explications ci-dessus sont des lectures simplifiées, pas des citations.
• Les guides d'agences nationales (ANSSI, CERT) : non consultés pour cet article, donc aucune recommandation chiffrée n'en est tirée.
• Les niveaux de l'ASVS et leur adaptation à une PME : non lus.
• La fréquence réelle des incidents pour les PME en Afrique de l'Ouest : non trouvée, nous ne donnons aucune statistique.
• Le seuil à partir duquel un audit externe est nécessaire : non établi.
• Les exigences légales locales en matière de notification d'incident : non vérifiées ici.

Sources consultées le 8 novembre 2026

• OWASP Top 10 : top10.owasp.org/2025 (lu le 8 novembre 2026 ; redirection depuis owasp.org/Top10/2025).
• OWASP ASVS : asvs.owasp.org (lu le 8 novembre 2026 ; version 5.0.0 du 30 mai 2025).
• OWASP Cheat Sheet Series : Authorization (lu le 8 novembre 2026).
• Next.js : How to think about data security in Next.js (page mise à jour le 6 octobre 2026, lue le 8 novembre 2026).
• Stripe : Receive Stripe events in your webhook endpoint (lu le 8 novembre 2026).

Pour aller plus loin

Pour une checklist de mise en production, voir la checklist Next.js pour PME. Pour les paiements, Next.js, Stripe et webhooks. Pour la propriété du code, qui possède le code, et pour les données personnelles, la protection des données en Afrique de l'Ouest.

Un site, une application ou un SaaS à cadrer, avec ces questions dans le cahier des charges ? Demandez-nous un devis écrit.