Dans la nuit du 3 au 4 septembre 2026, Communauto détecte une activité inhabituelle dans ses systèmes. Un employé avait lancé un script automatisé pour consulter et télécharger des dossiers de clients : noms, dates de naissance, adresses, numéros de permis de conduire. Les accès ont été coupés pendant la nuit et la police a été avisée. Selon l’entreprise, rien n’indique que les données ont été diffusées.

Peu importe l’état du site web de Communauto, aucun balayage de surface n’aurait répondu à la vraie question. Combien de dossiers un compte connecté peut-il extraire? Est-ce que quelqu’un le voit quand ça arrive?

C’est la différence entre regarder votre site de l’extérieur et le tester en profondeur. Les deux sont utiles. Par contre, ils ne répondent pas à la même question et l’ordre compte.

Ce qu’un balayage de surface voit

Un balayage de surface regarde ce que tout le monde peut voir de l’extérieur, sans se connecter. C’est ce que fait l’outil gratuit loi25.certi360.com que nous avons créé chez Certi360. En quelques minutes, il vérifie :

  • la configuration du domaine et du courriel (SPF, pour limiter l’usurpation de vos adresses) ;
  • le chiffrement HTTPS et la validité du certificat ;
  • les en-têtes de sécurité, comme HSTS (forcer le HTTPS) et CSP (limiter les scripts qui peuvent s’exécuter sur vos pages) ;
  • les témoins et traceurs déposés avant le consentement du visiteur ;
  • la présence d’une politique de confidentialité accessible.

C’est une photo de votre site web, celle que vos clients, vos partenaires et les attaquants voient en premier.

Je recommande de commencer par là pour une raison simple. Un analyste en sécurité coûte cher à l’heure. Le payer pour découvrir un en-tête manquant ou un traceur Google qui se charge avant le consentement, c’est gaspiller votre budget. Ces corrections, votre développeur ou votre fournisseur MSP peut souvent les faire en une journée.

Quand le rapport est propre, vous avez réglé les bases. Vous n’avez pas encore testé ce qui se passe derrière la page de connexion.

Ce qu’un balayage ne peut pas voir

En janvier 2026, un chercheur indépendant découvre qu’il peut lire les dossiers de soutien technique d’autres clients de Meta (conversations, fichiers joints, coordonnées). Il avait enchaîné plusieurs défauts d’autorisation : le serveur ne vérifiait pas si la personne qui demandait un dossier avait le droit de le voir. Meta a corrigé en avril, n’a trouvé aucune trace d’exploitation malveillante et lui a versé une prime de 78 000 $ US.

Le site de Meta n’avait pas de problème de certificat ni d’en-tête manquant. Le problème se trouvait dans la logique de l’application.

Un outil automatisé ne sait pas qui vous êtes. Il ne sait pas que la facture numéro 1042 appartient à madame Tremblay et que la facture 1043 appartient à monsieur Gagnon. Quand il demande la page, le serveur répond normalement. Pour l’outil, tout va bien.

Pour voir le problème, il faut se connecter avec le compte A, demander une ressource du compte B et constater que le site la livre. Ça demande une personne qui comprend ce que l’application est censée faire, avec plusieurs comptes de test.

Ce type de faille porte un nom : le contrôle d’accès défaillant. Il est au premier rang du OWASP Top 10 2025, la liste de référence des risques applicatifs. Selon les données compilées pour cette édition, toutes les applications testées présentaient une forme ou une autre de contrôle d’accès défaillant.

Ce n’est pas un cas rare. C’est le cas le plus fréquent.

Le même problème, en plus simple

Le 28 septembre 2026, la firme UpGuard publie une recherche sur Supabase, une base de données infonuagique très utilisée pour créer rapidement des applications web, souvent avec des outils de développement assisté par IA. Elle a trouvé plus de 16 000 bases dont les tables étaient lisibles par n’importe qui. Parmi les cas cités, un service d’immigration canadien exposait 5 000 dossiers d’utilisateurs, dont 884 mots de passe en clair.

La cause est presque toujours la même : les règles qui limitent chaque utilisateur à ses propres données étaient absentes ou inefficaces. Le site affichait les bonnes informations à la bonne personne. La base de données, elle, répondait à tout le monde. Votre site web peut être propre en surface et votre base de données grande ouverte.

Ce que couvre une analyse en profondeur

Chez Certi360, le test applicatif s’appuie sur l’OWASP ASVS (Application Security Verification Standard). La version 5.0 compte 345 exigences réparties en 17 chapitres et trois niveaux, selon la sensibilité de l’application. J’ai déjà expliqué ce standard en détail ici.

En pratique, l’analyste reçoit des comptes à différents niveaux de privilège (utilisateur, gestionnaire, administrateur). Il utilise des outils, mais il vérifie surtout à la main que chaque contrôle attendu existe réellement et résiste quand on le pousse.

Les éléments qui méritent d’être testés en profondeur

Voici ce qu’aucun balayage de surface ne peut confirmer à votre place. Je les présente dans le langage d’un dirigeant, pas d’un développeur.

Les données des autres clients

Est-ce qu’un client connecté peut voir la facture, le dossier ou le document d’un autre client en changeant un numéro? C’est exactement la faille de Meta.

Les fonctions réservées aux administrateurs

Un utilisateur ordinaire peut-il atteindre une page d’administration, exporter la liste des clients ou modifier un prix s’il connaît l’adresse?

La logique d’affaires

Peut-on appliquer un code promo deux fois, commander une quantité négative, sauter l’étape du paiement ou modifier le montant envoyé au processeur de paiement? Ce sont des failles propres à votre application. Aucun outil générique ne connaît vos règles.

La réinitialisation du mot de passe

C’est souvent la porte la plus faible. Le lien expire-t-il? Peut-on le réutiliser? Le site confirme-t-il qu’une adresse courriel existe dans votre base de clients?

La double authentification

Est-elle obligatoire là où elle doit l’être ou peut-on la contourner en passant par un autre chemin, comme l’application mobile?

Les sessions

Une session reste-t-elle active après la déconnexion ou après un changement de mot de passe? Un employé qui quitte l’entreprise garde-t-il un accès ouvert sur son téléphone?

La base de données derrière le site

Si votre application a été créée avec Supabase, Firebase ou un outil semblable, les règles qui limitent chaque utilisateur à ses propres données sont-elles activées et testées? C’est la question que 16 000 propriétaires d’applications ne se sont pas posée.

L’API derrière le site ou l’application mobile

L’écran affiche le prénom du client. L’API, elle, renvoie parfois le dossier complet, incluant la date de naissance et l’adresse. Le visiteur ne le voit pas, un attaquant oui.

Le téléversement de fichiers

Si vos clients ou candidats déposent des CV, des factures ou des photos, qu’est-ce qui empêche quelqu’un de déposer un fichier malveillant ou de consulter les fichiers des autres?

Les formulaires

Les validations faites dans le navigateur se contournent en quelques secondes. La vraie question est de savoir si le serveur vérifie lui aussi ce qu’il reçoit.

Les limites de volume

Un compte légitime peut-il consulter mille dossiers en une heure sans que rien ne bloque ni n’alerte? C’est le scénario de Communauto : un vrai compte, un script et des dossiers téléchargés un après l’autre. Un test en profondeur vérifie si l’application limite ce qu’un compte peut extraire, peu importe qui l’utilise.

La journalisation

Si un incident survient, pouvez-vous reconstituer qui a consulté quoi? Chez Communauto, c’est la détection d’une activité inhabituelle qui a permis de couper les accès pendant la nuit. Sans traces exploitables, impossible d’évaluer le risque de préjudice et de documenter l’incident comme la Loi 25 l’exige.

Votre site a-t-il vraiment besoin de ça?

Pas toujours. Et je préfère le dire.

Un site web sans connexion, sans formulaire qui recueille des renseignements personnels et sans paiement n’a pas besoin d’un test ASVS. Un balayage de surface, des mises à jour régulières et une bonne hygiène suffisent minimalement.

Par contre, dès que votre site comporte un espace client, un portail employé, un formulaire qui recueille des renseignements personnels, du paiement en ligne, une API ou une application mobile, la question change. Ce n’est plus seulement votre site web qui est exposé. Ce sont les données de vos clients.

Au Québec, la loi sur la protection des renseignements personnels dans le secteur privé exige des mesures de sécurité raisonnables compte tenu de la sensibilité des renseignements (article 10). Elle exige aussi une évaluation des facteurs relatifs à la vie privée (EFVP) pour tout projet de développement ou de refonte d’un système qui traite des renseignements personnels (article 3.3). Pour répondre honnêtement à cette évaluation, il faut savoir si les contrôles d’accès fonctionnent, pas seulement s’ils existent sur papier ou dans la promesse du fournisseur.

Pour un test ASVS sur une application web de PME, prévoyez entre 5 000 $ et 35 000 $ selon la profondeur du test, le nombre de fonctions, de rôles et d’API à couvrir. C’est le budget qu’on hésite à dépenser avant la mise en ligne et qu’on regrette de ne pas avoir dépensé après.

En pratique

Voici l’ordre que je recommande :

  1. Passez votre site dans loi25.certi360.com et corrigez ce qui ressort.
  2. Faites la liste de ce qui se trouve derrière une connexion : espace client, portail, API, application mobile, téléversement.
  3. Si cette liste n’est pas vide, planifiez un test applicatif selon l’ASVS, idéalement avant la mise en production ou avant une refonte importante.
  4. Préparez des comptes de test pour chaque rôle et nommez la personne qui signera l’autorisation du test.
  5. Exigez de votre fournisseur un rapport de test indépendant plutôt qu’une simple confirmation que « c’est sécuritaire ».
  6. Faites retester les corrections. Une faille déclarée corrigée n’est pas une faille vérifiée corrigée.

Les trois niveaux de test que nous offrons sont décrits sur notre page Test de sécurité.

Bref

Chez Communauto, c’est la détection qui a limité les dégâts. Chez Meta, c’est un chercheur externe qui a trouvé la faille. Dans les deux cas, la réponse ne se trouvait pas dans ce qu’un balayage du site web peut voir. Je ne sais pas combien de portails clients de PME québécoises sont dans la même situation aujourd’hui, mais je sais qu’aucun outil automatique ne pourra vous le dire.

Commencez par un test rapide de votre site web sur loi25.certi360.com. Pour aller plus loin, parlons-en.

Références