L'OWASP, c'est le nom qui revient dès que des développeurs parlent de sécurité web. L'acronyme signifie Open Worldwide Application Security Project. Il s'agit d'une fondation à but non lucratif qui publie gratuitement des guides, des listes de contrôle et des outils pour construire des logiciels plus difficiles à attaquer. Son document le plus connu, le Top 10 de l'OWASP, recense les failles de sécurité que l'on retrouve le plus souvent dans les sites et applications réels.

Pas besoin de savoir coder pour vous y intéresser. Si vous gérez une boutique, si vous faites appel à un freelance pour construire un site ou si vous choisissez une plateforme pour vendre, l'OWASP vous donne un vocabulaire commun et une grille de lecture. Il vous aide à poser les bonnes questions sur la protection des données de vos clients et de votre chiffre d'affaires.

Qu'est-ce que l'OWASP ?

L'OWASP est née en 2001 comme une communauté ouverte de professionnels de la sécurité. C'est aujourd'hui une fondation avec des antennes locales dans le monde entier. Tout ce qu'elle produit est libre et gratuit : documents, outils de test, supports de formation. Elle ne vend aucun produit et ne certifie aucune entreprise.

Ses projets les plus connus :

  • Le Top 10 de l'OWASP. Un document de sensibilisation qui classe les dix catégories de risques les plus critiques pour une application web. Il est mis à jour tous les trois ou quatre ans à partir de données issues de vrais tests de sécurité.
  • L'ASVS (Application Security Verification Standard). Une liste d'exigences de sécurité beaucoup plus détaillée, organisée en niveaux, qui sert à tester ou à cadrer une application.
  • Les cheat sheets. De courtes fiches pratiques sur un sujet précis, comme le stockage des mots de passe ou la gestion des sessions.
  • Des outils comme ZAP. Un scanner gratuit qui teste un site à la recherche de faiblesses courantes.

L'OWASP n'est ni une loi, ni une réglementation, ni une certification. Personne n'est « certifié OWASP ». Quand une agence affirme que son travail « suit l'OWASP », cela veut dire qu'elle s'appuie sur ces référentiels. C'est bon signe, mais c'est une affirmation que vous pouvez lui demander de détailler. L'OWASP n'est pas non plus la norme PCI DSS, qui s'applique dès que l'on manipule des paiements par carte. Les deux se recoupent : PCI DSS exige une protection contre les vulnérabilités courantes, et l'OWASP sert souvent à le démontrer.

Pourquoi c'est important

La plupart des attaques contre les petites boutiques ne sont pas ciblées. Des robots scannent chaque jour des millions de sites à la recherche de failles connues : une extension obsolète, une page d'administration avec un mot de passe par défaut, un formulaire qui laisse passer des commandes vers la base de données. Le Top 10 décrit précisément ces faiblesses. Un site qui les ignore finit par être repéré.

Les conséquences pour un e-commerçant sont très concrètes. Prenez une boutique qui traite 800 commandes par mois avec un panier moyen de 55 €, soit environ 44 000 € de chiffre d'affaires mensuel. Un attaquant exploite une vieille extension et injecte un script qui copie les données de carte sur la page de paiement. La boutique reste fermée cinq jours, le temps qu'un développeur fasse le ménage. Cela représente environ 7 300 € de ventes perdues, plus peut-être 3 000 € d'intervention en urgence. Viennent ensuite les notifications aux clients concernés, les questions éventuelles du prestataire de paiement et les avis du type « ma carte a été utilisée après un achat ici ». Au final, la facture dépasse souvent plusieurs fois la perte directe.

Pour les fondateurs et les marques qui font appel à des développeurs, l'OWASP a un autre intérêt. Il fournit une norme à inscrire dans un contrat. « Le site doit traiter les risques du Top 10 de l'OWASP » est une exigence claire et vérifiable. « Le site doit être sécurisé » ne l'est pas.

Comment ça marche

Le Top 10 est la porte d'entrée pour la plupart des gens. L'édition 2021 reste la plus citée dans les contrats et les formations. Voici ses catégories en langage courant, avec un exemple tiré d'une boutique pour chacune :

  • Contrôle d'accès défaillant. Un utilisateur voit ou modifie ce qui ne le regarde pas. Exemple : changer un chiffre dans l'URL affiche la commande d'un autre client.
  • Défaillances cryptographiques. Des données sensibles mal chiffrées, en transit ou au repos. Exemple : un site sans HTTPS, ou des mots de passe stockés en clair.
  • Injection. Une saisie de l'utilisateur est exécutée comme une commande. Exemple : un champ de recherche qui permet de lire la base clients (injection SQL) ou d'exécuter des scripts dans le navigateur des autres visiteurs (cross-site scripting).
  • Conception non sécurisée. La faille est dans la logique, pas dans le code. Exemple : un code promo applicable un nombre illimité de fois.
  • Mauvaise configuration de sécurité. Réglages par défaut, interfaces d'administration ouvertes ou messages d'erreur détaillés visibles du public.
  • Composants vulnérables et obsolètes. Extensions, thèmes ou bibliothèques aux failles connues, jamais mis à jour.
  • Défaillances d'identification et d'authentification. Règles de mot de passe laxistes, tentatives de connexion illimitées, sessions qui n'expirent jamais. L'authentification multifacteur répond à une partie du problème.
  • Défaillances d'intégrité des logiciels et des données. Mises à jour ou scripts chargés depuis des sources non fiables, sans vérification.
  • Journalisation et surveillance insuffisantes. Une attaque a lieu et personne ne s'en rend compte pendant des semaines.
  • Falsification de requêtes côté serveur (SSRF). Le serveur peut être piégé pour envoyer des requêtes vers des systèmes internes qu'il ne devrait pas atteindre.

La mise à jour 2025 conserve l'essentiel de ces idées. Elle intègre la SSRF au contrôle d'accès et ajoute les failles de la chaîne d'approvisionnement logicielle ainsi que la mauvaise gestion des erreurs et des situations imprévues. Les intitulés évoluent d'une édition à l'autre, mais les risques de fond restent les mêmes.

Un audit de sécurité passe généralement ces catégories en revue une par une. Le testeur tente chaque type d'attaque sur l'application, note ce qui fonctionne et classe les résultats par gravité. Le développeur corrige, puis le testeur vérifie à nouveau.

Repères et exemples

Quelques points de repère réalistes :

  • Les composants obsolètes sont le problème classique des petites boutiques. Sur les boutiques open source auto-hébergées, une extension non mise à jour fait partie des portes d'entrée les plus fréquentes.
  • Un premier scan automatique ne coûte rien. Un outil comme ZAP repère les problèmes évidents en une heure. Il ne remplace pas un test mené par un humain.
  • Un test d'intrusion professionnel sur une petite application web coûte souvent de quelques milliers à environ 15 000 €, selon le périmètre et la profondeur.
  • Un site réalisé par un freelance pour 6 000 € inclut rarement un audit de sécurité. Demandez si c'est le cas et sur quelle base le développeur vérifie son travail.

Situations typiques : une créatrice qui vend sur une plateforme hébergée s'en remet au prestataire pour la quasi-totalité du Top 10. Une marque avec une boutique sur mesure partage la responsabilité avec son développeur et son hébergeur. Une entreprise qui exploite sa propre application web porte chaque ligne de la liste.

Erreurs fréquentes

  • Prendre le Top 10 pour une liste exhaustive. C'est un document de sensibilisation aux risques les plus courants, pas à tous les risques. Pour un cahier des charges complet, utilisez l'ASVS.
  • Penser qu'une petite boutique n'intéresse personne. Les robots ne regardent pas votre chiffre d'affaires avant de scanner.
  • Installer des extensions sans jamais les mettre à jour. Chaque module ajouté est du code dont vous êtes responsable.
  • Se contenter de « on suit l'OWASP ». Demandez quel document, quel niveau et comment cela a été testé.
  • Sécuriser le code et oublier les comptes. Un mot de passe administrateur partagé par email annule beaucoup de bon travail technique.

Bonnes pratiques

  • Inscrivez l'OWASP dans vos contrats. Quand vous engagez un développeur ou une agence, exigez que le Top 10 soit traité et qu'un rapport de scan vous soit remis à la livraison.
  • Mettez tout à jour. Thèmes, extensions, bibliothèques et logiciels serveur. Planifiez-le chaque mois si rien ne se fait automatiquement.
  • Limitez les accès administrateur. Chaque personne a son propre compte avec uniquement les droits nécessaires, et vous retirez l'accès au départ d'un collaborateur.
  • Utilisez des mots de passe forts, uniques, et un gestionnaire de mots de passe. Activez un second facteur partout où un outil le propose.
  • Lancez un scan gratuit après chaque changement important. Une nouvelle étape de checkout ou une nouvelle intégration, c'est le bon moment pour vérifier.
  • Privilégiez les outils hébergés où la sécurité est le métier de quelqu'un. Pour la plupart des petits vendeurs, cela retire l'essentiel du Top 10 de votre liste de tâches.

Dans Roctify

Roctify est une plateforme hébergée. Le code, les serveurs et les mises à jour derrière votre boutique sont maintenus par l'équipe Roctify, pas par vous ni par un freelance. Chaque page est servie en HTTPS avec un certificat SSL gratuit, et il n'y a pas d'extensions tierces à installer puis à oublier de mettre à jour. Les données de carte sont saisies dans le parcours de paiement Stripe ou PayPal au checkout, si bien que votre boutique ne stocke pas de numéros de carte.

Votre part se situe au niveau des comptes : un mot de passe fort et unique, une vraie attention à qui a accès à quoi et, sur la formule Pro, un identifiant par membre de l'équipe plutôt qu'un compte partagé. Surveillez vos codes promo et vos réglages comme vous le feriez pour n'importe quel outil de gestion.

FAQ

L'OWASP est-elle une certification que je peux obtenir pour ma boutique ?

Non. L'OWASP ne certifie ni les sites ni les entreprises. Elle publie des normes et des guides gratuits. Un développeur ou un auditeur peut tester votre site par rapport au Top 10 ou à l'ASVS et vous remettre un rapport, mais il n'existe pas de label officiel OWASP.

À quelle fréquence le Top 10 est-il mis à jour ?

Environ tous les trois à quatre ans, à partir de données fournies par des cabinets de tests de sécurité et d'une enquête auprès de la communauté. Les dernières éditions datent de 2017, 2021 et 2025. Les catégories évoluent lentement, donc l'essentiel des conseils reste valable d'une édition à l'autre.

Dois-je connaître l'OWASP si j'utilise une plateforme hébergée ?

Pas dans le détail. La plateforme prend en charge la plupart des points techniques. Connaître les grandes catégories reste utile pour juger les réponses d'un prestataire sur la sécurité et éviter les risques qui restent de votre côté, comme les mots de passe faibles ou les comptes partagés.