Audit sécurité d'un site web ou d'une application : ce que nous vérifions, dans quel ordre

Avant l'audit sécurité du site internet : ce que vous vérifiez vous-même en dix minutes

Une partie des problèmes se voit avec un simple navigateur. Ces essais ne remplacent pas un audit, mais ils vous disent déjà si l'urgence est forte. Faites-les dans une fenêtre de navigation privée, où vous n'êtes connecté à rien, pour voir votre application comme la voit un inconnu.

Regardez d'abord la barre d'adresse. L'adresse doit commencer par https et le navigateur doit montrer un cadenas, sans avertissement. Sans lui, tout ce qui circule entre l'écran et le serveur passe en clair, mots de passe compris. Tapez aussi l'adresse en http, sans le s : un site bien réglé vous renvoie de lui-même vers la version protégée.

Connectez-vous ensuite normalement, ouvrez une page réservée, une fiche client ou un tableau de bord, et copiez son adresse. Déconnectez-vous, ouvrez une fenêtre privée et collez-la. Si la page s'ouvre, ou si elle apparaît une seconde avant de vous renvoyer vers la connexion, l'application envoie ses données à quiconque connaît l'adresse. Refaites l'essai avec l'adresse d'une facture ou d'un fichier joint.

Tapez ensuite, derrière le nom de votre site, les adresses que tout le monde essaie : /admin, /administration, /dashboard. Une page d'administration qui répond reste acceptable si elle demande un mot de passe solide. Celle qui s'ouvre sans rien demander se ferme aujourd'hui, avant tout le reste.

Provoquez enfin une erreur : ajoutez des lettres au hasard à la fin d'une adresse, ou validez un formulaire rempli n'importe comment. Une application bien réglée répond par un message court, du type « page introuvable ». Si vous voyez apparaître des lignes de code, des noms de fichiers ou le nom de la base de données, l'application raconte son fonctionnement interne à qui veut le lire.

Pour aller un cran plus loin, l'analyseur de site regarde votre page d'accueil de l'extérieur en quelques minutes, le https compris, et vous rend chaque défaut constaté avec sa preuve. Il voit ce que voit un visiteur. Ce qui se passe derrière la connexion demande quelqu'un qui lit le code.

Les mots de passe et les clés écrits dans le code, premier point d'un audit applicatif

Une application parle à d'autres services : sa base de données, l'outil de paiement, le service qui envoie les courriels, parfois un assistant comme ChatGPT. Pour chacun, elle détient une clé, une longue suite de caractères qui fonctionne comme un mot de passe. Celui qui possède la clé de la base peut la lire en entier, et celui qui possède la clé du paiement peut agir sur vos encaissements.

Quand le code avance vite, ces clés finissent souvent en toutes lettres dans le code lui-même, parce que c'est la façon la plus rapide de faire tourner la démo. Le risque change de taille dès que ce code part dans un dépôt partagé, chez un prestataire, ou dans la partie de l'application que le navigateur télécharge : n'importe quel visiteur peut alors lire la clé avec les outils intégrés à son navigateur.

Nous commençons par là parce que la recherche est rapide et que le risque est le plus grave de toute la liste : une seule clé peut ouvrir toutes les données d'un coup. La correction ne touche pas au fonctionnement de l'application. On sort la clé du code, on la range dans l'espace que l'hébergeur prévoit à cet effet, et l'application va la lire là.

Déplacer la clé ne suffit pas, il faut aussi la changer. Une clé qui a traîné dans le code doit être considérée comme connue : n'importe qui ayant eu accès au dépôt a pu la copier, anciens prestataires compris. On en crée une neuve chez le service concerné et on désactive l'ancienne. Sans ce geste, la copie faite il y a six mois continue de fonctionner.

Le dépôt garde la mémoire de tout ce qui y est passé. Un code peut ne plus contenir aucune clé aujourd'hui et en contenir une dans une version ancienne, toujours consultable. L'audit fouille donc tout l'historique. Il y cherche aussi les mots de passe d'administration oubliés dans un fichier de réglages ou dans un commentaire laissé « pour plus tard ».

Qui peut lire les données de qui : comptes, droits et séparation entre clients

La question suivante concerne les gens qui ont un compte. Un utilisateur connecté ne devrait voir que ce qui le concerne, et ne faire que ce que son rôle autorise. Dans une application construite vite, ces deux règles existent souvent à l'écran et nulle part ailleurs : le bouton « supprimer » n'apparaît pas pour un simple employé, mais l'action reste possible pour qui sait la déclencher sans passer par le bouton.

La protection se joue sur le serveur, qui doit vérifier à chaque demande si la personne a le droit de lire cette fiche, de modifier ce montant ou d'exporter cette liste. L'audit rejoue les demandes de l'application sans passer par ses écrans, avec des comptes de niveaux différents, et note celles que le serveur accepte alors qu'il devrait les refuser.

Le test le plus parlant tient en une manipulation. Beaucoup d'applications identifient une fiche par un numéro visible dans l'adresse, du type /factures/1042. Un client qui remplace 1042 par 1041 devrait recevoir un refus. S'il voit la facture d'un autre, l'application ne vérifie pas à qui appartient ce qu'elle renvoie, et toutes les pages construites de la même façon sont probablement touchées.

Le cas le plus sérieux concerne les applications qui servent plusieurs entreprises clientes, chacune avec ses données, comme un logiciel de gestion vendu à des cabinets comptables. Toutes les données vivent en général dans la même base. Une seule recherche qui oublie de filtrer par client, et le cabinet A voit les dossiers du cabinet B. Une démo ne compte qu'un client, alors ce défaut n'y apparaît jamais.

Restent les comptes eux-mêmes. La liste de ceux qui ont des droits d'administration contient souvent un nom qui n'a plus rien à faire là, le prestataire de la première version par exemple. Nous regardons aussi la porte d'entrée : combien d'essais de mot de passe sont permis, et si les comptes d'administration demandent un code reçu sur le téléphone.

Les formulaires et les envois de fichiers : ce qu'un formulaire doit refuser

Chaque formulaire est une porte que vous ouvrez volontairement au public. Quelqu'un tape quelque chose, et votre application le range dans sa base, l'envoie par courriel ou le montre à d'autres utilisateurs. La règle tient en une phrase : l'application ne fait jamais confiance à ce qu'on lui envoie, et vérifie chaque champ sur le serveur, même quand le navigateur l'a déjà vérifié.

Un formulaire doit refuser ce qui ne ressemble pas à ce qu'il attend. Un champ « code postal » n'accepte pas trois pages de texte. Un champ « nom » range ce qu'on y tape comme du texte inerte, sans jamais l'exécuter. Le cas classique, que les techniciens appellent une injection, est celui d'un champ où quelqu'un tape une instruction destinée à la base de données, et où l'application l'exécute au lieu de l'enregistrer.

Une variante touche ce que voient les autres utilisateurs. Un message laissé dans un champ « commentaire » peut contenir un petit programme qui se lancera dans le navigateur de chaque personne qui ouvre la fiche, administrateurs compris. L'application doit transformer ce qu'elle reçoit en simple texte avant de le montrer à l'écran.

Les envois de fichiers demandent plus de précautions encore. Un formulaire qui accepte une photo ou une pièce justificative doit vérifier ce que contient le fichier, et pas seulement son nom, car un fichier appelé photo.jpg peut contenir tout autre chose. Il fixe une taille maximale, range les fichiers hors de portée directe du public, et ne les rend qu'aux personnes autorisées.

Ce rangement pèse lourd dès que les fichiers sont sensibles, des pièces d'identité ou des bulletins de salaire par exemple. Un dossier de stockage laissé public, dont l'adresse se devine, met tous ces documents à disposition de qui la trouve. Les formulaires ouverts attirent aussi des robots qui les remplissent en masse : une limite sur le nombre d'envois et un contrôle anti-robot évitent de voir votre base se remplir de faux comptes.

Les briques que vous n'avez pas choisies, et leurs mises à jour

Aucune application n'est écrite en entier par ceux qui la construisent. Elle s'appuie sur des dizaines, souvent des centaines de briques déjà faites, publiées par d'autres, pour gérer les connexions ou les paiements. Quand un outil écrit le code à votre place, il ajoute ces briques lui-même, au fil des demandes, et personne ne décide vraiment lesquelles entrent dans votre application.

Chaque brique a ses propres failles, découvertes avec le temps, publiées puis corrigées dans des versions plus récentes. Une application restée sur une version ancienne garde la faille, décrite publiquement, parfois avec le mode d'emploi pour s'en servir. L'audit compare chaque brique installée aux listes publiques de failles connues, puis garde celles qui posent un problème réel dans votre cas.

Il arrive aussi qu'un assistant de code propose une brique abandonnée depuis des années, ou même une brique qui n'existe pas. Le second cas est un piège connu : quelqu'un peut publier, sous ce nom inventé, une brique piégée qui s'installera à la première occasion. Nous vérifions que chaque brique existe et qu'elle est encore entretenue, et nous signalons celles qui ne servent plus à rien.

Mettre à jour ne se fait pas d'un clic dans une application sans tests automatiques. Une nouvelle version peut changer un comportement, et sans tests personne ne sait si la mise à jour a cassé la page de paiement avant qu'un client s'en plaigne. Alors on n'ose plus toucher, et les versions vieillissent. La page sur la dette technique décrit ce mécanisme en détail.

Le compte rendu sépare donc deux familles : les briques à mettre à jour tout de suite, parce que leur faille touche votre usage, et celles qui peuvent attendre le prochain chantier. Un outil automatique sort facilement plusieurs centaines d'alertes, dont beaucoup ne vous concernent pas. Rendues sans tri, elles ne vous aident pas à décider quoi que ce soit.

L'hébergement, les sauvegardes et la restauration qu'on a vraiment essayée

L'audit regarde ensuite où l'application tourne et qui en détient les accès. Souvent, l'outil ou le prestataire a ouvert l'hébergement sur un compte à son nom. Le jour où la relation s'arrête, l'entreprise découvre qu'elle ne possède ni le serveur ni la base de données, parfois même pas le nom de domaine. Nous vérifions à quel nom sont ouverts ces comptes, et qui peut s'y connecter.

Les réglages de l'hébergement comptent aussi. Nous cherchons par exemple une base de données joignable depuis tout internet, alors que seule l'application devrait lui parler, ou un mode « développement » resté actif en production, qui montre le détail technique de chaque erreur. Ces points se règlent dans l'hébergement, sans toucher au code, et vite une fois repérés.

Viennent ensuite les sauvegardes. La question « avez-vous des sauvegardes ? » reçoit le plus souvent un oui. Les questions utiles sont ailleurs : à quel rythme, gardées où, pendant combien de temps, et quelqu'un a-t-il déjà essayé d'en restaurer une ? Une sauvegarde rangée sur le même compte que l'application disparaît avec elle si ce compte est piraté ou supprimé.

Une sauvegarde jamais restaurée reste une promesse. Le jour où il faut s'en servir, on découvre parfois qu'elle contient la base mais pas les fichiers envoyés par les clients, ou que personne ne sait la remettre en place. L'audit demande donc un essai réel : restaurer la dernière sauvegarde sur une copie de l'application, et chronométrer. Ce chiffre vous dit combien de temps votre activité s'arrêterait si tout disparaissait.

Si vous voulez un hébergement dont vous détenez vous-même les accès, notre façon de faire est décrite sur la page hébergement. Rien ne vous oblige à changer d'hébergeur pour autant : l'audit vous dit ce qu'il faut régler chez celui que vous avez déjà.

Le compte rendu d'un audit d'application web : ce qu'il doit contenir pour que vous puissiez décider

Un document de cent pages rempli de termes techniques n'aide pas un dirigeant. Vous avez besoin de savoir quoi corriger en premier, et ce que cela coûte. Le compte rendu doit donc être écrit pour vous, avec un résumé d'une page en tête, et le détail technique rangé derrière pour la personne qui fera les corrections.

Chaque point trouvé doit être expliqué en une ou deux phrases de ce qui peut arriver. « Les factures de tous les clients sont lisibles par n'importe quel client connecté » se comprend sans formation. « Contrôle d'accès défaillant sur un point d'entrée » ne se comprend pas, même si c'est exact. Si vous devez rappeler le prestataire pour comprendre une ligne, la ligne est mal écrite.

Les points doivent ensuite être classés par risque, à partir de deux questions : quelles données sont exposées, et à qui ? Un classement en trois niveaux suffit en général. Ce qui expose des données personnelles ou de l'argent se corrige cette semaine. Ce qui deviendrait grave en cas d'incident, une sauvegarde jamais essayée par exemple, se corrige dans le mois. Le reste se planifie.

Chaque correction doit être chiffrée, en temps et en argent. Une faille grave qui se corrige en une heure se règle tout de suite. Une fragilité moyenne qui demande trois semaines de travail peut attendre une refonte déjà prévue. Sans chiffrage, vous ne pouvez pas arbitrer, et vous finissez par tout faire d'un coup ou par ne rien faire.

Le compte rendu dit aussi ce qui tient. Savoir que la connexion des utilisateurs est solide, ou que les paiements passent par un service qui ne laisse transiter aucun numéro de carte par votre application, vous évite de dépenser là où ce n'est pas utile. Et si refaire coûte moins cher que corriger, le compte rendu doit le dire, avant que vous ne signiez quoi que ce soit pour la suite.

Combien de temps prend un audit de sécurité d'une application

La durée dépend moins du nombre de pages que du nombre de façons d'entrer, et de ce qu'il y a derrière. Une application interne avec un seul type d'utilisateur, une base de données et aucun paiement se relit vite. Une plateforme qui mélange clients, administrateurs et partenaires demande beaucoup plus, parce que chaque type de compte multiplie les vérifications sur les droits.

Pour donner un ordre de grandeur, la relecture de sécurité d'une application de taille modeste se compte en jours. Elle s'allonge quand l'application sert plusieurs entreprises clientes, manipule des données de santé ou des paiements, ou quand plusieurs outils et plusieurs personnes se sont succédé dans le code, chacun avec ses habitudes.

L'accès fait varier la durée plus que tout le reste. Avec le code, son historique, une lecture de l'hébergement et deux comptes de test de niveaux différents, l'audit avance sans attendre. Sans le code, on ne peut tester que de l'extérieur, ce qui prend plus de temps et laisse des zones dans l'ombre. Rassemblez ces accès avant le premier jour.

La mémoire de l'application pèse aussi. Quand plus personne ne sait comment elle est mise en ligne, ni quels services extérieurs elle utilise, il faut reconstituer tout cela avant de commencer les vérifications. Ce temps-là sert deux fois : la carte dessinée pendant l'audit resservira à chaque personne qui touchera l'application ensuite.

Demandez le délai par écrit, avec le prix, avant de commencer. Un prestataire sérieux peut avoir besoin de jeter un œil à l'application avant de s'engager, et c'est normal. Après ce premier regard, il doit pouvoir écrire ce qu'il va vérifier, en combien de temps, et ce que vous recevrez à la fin.

Ce qu'on fait des trouvailles, et par où commencer

Le compte rendu en main, l'ordre des corrections suit une règle simple. D'abord ce qui expose des données à quelqu'un qui ne devrait pas les voir, ensuite ce qui empêcherait de repartir après un incident, enfin ce qui rendra l'application plus solide dans la durée. Une clé de paiement visible dans le navigateur passe avant une brique à mettre à jour, même si la brique déclenche une alerte plus impressionnante.

Les premières corrections sont souvent les plus courtes, et vos utilisateurs ne voient aucune différence : changer les clés, fermer les comptes oubliés, ajouter la vérification des droits sur les pages qui en manquent, mettre la base de données hors de portée d'internet. Aucune ne demande de refaire l'application.

Pour la suite, nous reprenons l'application là où elle en est : secrets sortis du code, droits d'accès, sauvegardes, formulaires et envois de fichiers contrôlés, tests automatiques sur les parcours qui comptent, hébergement que vous contrôlez. Le code reste dans votre dépôt, et vous pouvez continuer avec l'outil qui l'a écrit. La page reprise d'une application codée vite décrit cette façon de travailler.

Le Groupe des Arbitres Genevois gérait ses inscriptions dans un site dont le fonctionnement n'était plus documenté. Les pièces d'identité des candidats y étaient dispersées, sans contrôle d'accès clair. Avant de reconstruire quoi que ce soit, nous avons récupéré les 557 inscrits et les 18 sessions, pour que rien ne se perde pendant les travaux.

Nous avons placé les 1 355 pièces d'identité derrière un accès réservé au comité, et mené une revue de sécurité des formulaires, des envois de fichiers et des accès administrateur. Nous avons aussi trouvé pourquoi des courriels n'arrivaient pas en production. Le détail est sur la page du cas GAG.

Quand refaire l'audit, et quand il ne sert à rien

Un audit décrit l'application à une date donnée, et il vieillit dès que le code change. Trois moments justifient de le refaire, au moins en partie : l'ajout d'une fonction qui touche aux données sensibles ou à l'argent, le changement d'outil ou de prestataire, et le départ de la personne qui connaissait l'application.

Une nouvelle fonction se vérifie sur elle-même, sans tout reprendre : qui peut s'en servir, quelles données elle lit, ce qu'elle accepte en entrée. La vérification reste courte quand l'application a déjà été consolidée et que des tests automatiques couvrent les parcours qui comptent.

Un changement d'outil, de Lovable vers Cursor par exemple, ou l'arrivée d'un nouveau prestataire, appelle un regard neuf : chacun a ses habitudes, et les protections posées par l'un ne sont pas toujours respectées par l'autre. Le départ d'un développeur impose, le jour même, de fermer ses accès et de changer les clés et les mots de passe qu'il connaissait.

Pour une équipe qui modifie son application chaque semaine, un audit ponctuel ne suffit plus, et la vérification doit se brancher sur chaque modification. Chez Hairdex, où trois développeurs font déjà écrire du code par des assistants, nous formons l'équipe sur ses propres dépôts : tests d'abord sur les parcours qui touchent au patient, revue de code branchée sur chaque modification proposée.

Un audit ne sert à rien sur un prototype sans données réelles. Si votre application n'a servi qu'à des démonstrations, avec des données inventées, et que personne d'extérieur n'y a de compte, payer pour la sécuriser revient à blinder une maquette. Décidez d'abord si l'idée tient, et nous vous dirons la même chose si vous nous appelez. Gardez deux réflexes : aucune vraie donnée dedans, aucune clé de paiement réelle dans le code.

La réponse change le jour où le premier vrai client se connecte, ou le jour où un vrai fichier client est importé. L'audit se fait à ce moment-là, avant d'ouvrir plus largement. Le guide du vibe coding vous aide à situer votre application entre la maquette et l'outil dont votre entreprise dépend.