Étude de cas : un fichier d'installation laissé en ligne ouvre le back-office d'un restaurant

Chiffres clés

De quelle entreprise parle-t-on ?

Il s'agit d'un restaurant (Client D, anonymisé, domaine client-d.example) qui possède un site vitrine codé sur mesure, avec un module de réservation et de commande à emporter. Il n'y a ni équipe sécurité ni intégrateur identifié. C'est la situation typique d'une très petite entreprise : le site a été livré un jour et n'a plus été relu depuis.

Quel périmètre et quelle autorisation ?

Le rapport éclair couvre le site vitrine et les réservations, avec un accès d'abord anonyme, puis une session administrateur obtenue comme preuve. Une autorisation écrite précède ce type de test. Selon le rapport, la session n'a servi qu'à constater l'accès, aucune réservation n'a été lue et aucun changement n'a été effectué. Le test n'a émis aucune requête d'écriture sur le site, et le cookie de session local a été détruit.

Qu'avons-nous trouvé ?

Un seul constat, mais de sévérité High : un fichier d'installation de base de données accessible publiquement, qui expose le compte administrateur par défaut.

Le rapport classe la probabilité d'exploitation comme fréquente (trois requêtes), l'impact comme élevé (données clients et prise de contrôle du site) et la complexité de correction comme basique. Les recherches rapides d'autres sauvegardes, de fichiers de configuration et d'interfaces de gestion de base ont toutes donné un résultat négatif.

Comment la chaîne d'attaque fonctionne-t-elle ?

Elle enchaîne trois étapes simples, sans aucune technique avancée.

1. Le fichier d'installation est téléchargeable par n'importe qui et répond normalement. Il contient la création du compte administrateur avec l'empreinte de son mot de passe.
2. Cette empreinte correspond à la valeur d'exemple que reprennent de nombreux tutoriels et frameworks. Le mot de passe en clair associé est donc connu de tous, et il n'avait jamais été remplacé en production.
3. Le panneau d'administration accepte la connexion, ce qui ouvre le tableau de bord.

Le tableau de bord donne accès à la lecture, à la modification et à la suppression de toutes les réservations et commandes, avec le nom, le téléphone et l'adresse e-mail des clients. Un attaquant pourrait aussi modifier la carte et les bannières, ou utiliser les adresses pour des messages d'hameçonnage crédibles. L'effet est équivalent à un export contrôlé de la base métier. Le mot de passe par défaut n'est pas reproduit ici, et le rapport ne détaille volontairement pas les chemins d'administration.

Qu'est-ce qui tenait ?

Peu de surface était exposée. Le serveur web et le langage étaient classiques, aucun CMS vulnérable n'a été identifié, et les recherches d'autres sauvegardes, de fichiers de variables d'environnement et d'outils de gestion de base de données ont toutes renvoyé une erreur « introuvable ». L'API publique n'existait pas. Le problème tenait donc à un seul fichier oublié et à un seul identifiant jamais changé. C'est aussi ce qui rend la correction rapide.

Quels correctifs recommandons-nous ?

La complexité est basique, et les actions sont à faire dans cet ordre.

• Supprimer le fichier d'installation de la racine publique du site, et bloquer l'accès aux sauvegardes et aux listes de fichiers.
• Changer immédiatement le mot de passe administrateur, par une valeur longue et unique, et chercher dans les journaux d'accès si le fichier a déjà été téléchargé.
• Considérer le compte comme compromis tant que ce contrôle n'a pas eu lieu : prévenir les clients concernés si un accès non légitime est constaté.
• Mettre en place un déploiement qui n'envoie que les fichiers nécessaires, sans le dossier du projet complet.
• Retirer les comptes et mots de passe d'exemple de tout script d'installation avant la mise en production.

Ces pratiques correspondent à la catégorie « mauvaise configuration de sécurité » du Top 10 OWASP et aux recommandations de la CNIL sur la sécurité des données personnelles, qui demandent de gérer strictement les authentifiants et de limiter les accès. Les adresses e-mail et numéros de téléphone d'un carnet de réservations sont des données personnelles, ce qui rend l'exposition sensible au regard du RGPD.

Ce que ça change pour un agent IA

Un restaurant n'a pas d'agent IA dans ce cas précis, mais le schéma se transpose directement. Beaucoup de petites équipes branchent aujourd'hui un agent sur leur back-office pour répondre aux clients, confirmer des réservations ou préparer des commandes. L'agent reçoit alors un accès, souvent celui d'un administrateur, et hérite de toutes les faiblesses de ce back-office.

• Un agent agit avec les droits qu'on lui donne. Si le back-office s'ouvre avec un compte par défaut, quiconque le trouve contrôle aussi ce que l'agent peut lire et modifier. Voir notre guide de limitation de l'agentivité excessive.
• Les secrets doivent rester hors de la racine publique. Un fichier d'installation, un export, un fichier de variables d'environnement ou un historique de dépôt peuvent contenir des clés d'outils que l'agent utilise. Nos articles sur les secrets dans l'historique de dépôt et les variables publiques qui exposent des secrets détaillent le risque.
• Un agent lit des données personnelles à grande échelle. S'il peut lister les réservations, une injection de prompt peut les faire sortir. Voir notre étude sur les fuites de données par les chatbots.
• Les identifiants d'installation sont un classique. Avant de brancher un agent, vérifier qu'aucun compte d'exemple ne subsiste dans l'outil auquel il se connecte.

C'est le type de vérification qu'un red team d'agent IA place au début, avant de tester l'agent lui-même : l'agent n'est jamais plus sûr que le système qu'il pilote. Pour le cadre général, consultez notre page sur la sécurité des agents IA. Le même principe de contrôle d'accès absent apparaît dans nos études sur un webhook n8n et sur un abonnement contournable, ainsi que dans le cas du SaaS de rédaction IA.

Quel résultat pour le client ?

Le client a reçu un rapport éclair avec la chaîne prouvée et un plan de correction de quelques minutes de travail : retirer le fichier, changer le mot de passe, bloquer les sauvegardes. Pour un restaurant, ce type de correction se fait sans projet ni budget. Le point à retenir est la vitesse : une faille évitable en trois requêtes ne demande pas d'expertise pour être exploitée, ni pour être fermée. Si vous souhaitez un regard sur un agent branché à un outil métier, notre offre Red Team Agent Express démarre à 1 900 euros sur cinq jours.

Les autres études de cas

• Webhook n8n : comptes administrateur ouverts
• Paywall Supabase contourné en deux requêtes
• Application SaaS de rédaction IA
• Plateforme d’échange de crypto-actifs