Guide · Surface externe
Ce que votre site expose sans le vouloir
Un site public révèle forcément des informations pour fonctionner. Le travail consiste à distinguer ce qui est nécessaire, ce qui aide seulement au diagnostic et ce qui ouvre réellement un accès ou divulgue une donnée.
Réponse courte
Quelles informations un site web peut-il exposer publiquement ?
Son DNS, son certificat TLS, ses réponses HTTP, ses en-têtes, son HTML, ses scripts, ses feuilles de style, ses chemins publics et les documents indexés sont observables sans compte. Ces éléments peuvent révéler des fournisseurs, des technologies, des points d’entrée et parfois des versions.
Une empreinte technique n’est pas automatiquement une vulnérabilité. La priorité va aux secrets, données personnelles, sauvegardes, interfaces sensibles et versions réellement vulnérables qui sont accessibles. Vérifiez sur un site que vous contrôlez et documentez la preuve avant de corriger.
Ce que le site doit montrer pour fonctionner
Le navigateur reçoit une adresse IP, un certificat, des en-têtes et des fichiers. Le code côté client est, par définition, livré au visiteur. Les noms de services externes apparaissent souvent dans les requêtes vers les polices, statistiques, paiements, vidéos ou formulaires.
Cette visibilité est normale. Elle devient un problème quand une information inutile facilite une attaque, quand un fichier privé est servi ou quand une interface sensible est exposée sans protection adaptée.
À retenir
Réduire l’exposition ne signifie pas cacher toute technologie; cela signifie ne publier que ce qui sert réellement le visiteur et l’exploitation du site.
Le nom d’un serveur est un indice, pas un verdict
Un en-tête, un chemin, un cookie ou la structure d’un fichier peut suggérer un serveur, un CMS ou un framework. OWASP décrit cette reconnaissance comme une étape d’inventaire : elle aide à formuler des hypothèses et à choisir les vérifications suivantes.
Masquer une bannière de version réduit un indice facile, mais ne corrige pas une version vulnérable. À l’inverse, reconnaître WordPress ne prouve pas qu’une extension particulière est installée ni exploitable.
Détail technique
Traitez séparément la divulgation d’information et la faiblesse qu’elle pourrait aider à viser. La première peut mériter un nettoyage; la seconde exige une preuve propre.
Ce que les moteurs et archives ont déjà vu
Les moteurs peuvent révéler des sous-domaines, documents bureautiques, anciens chemins, environnements de test ou messages d’erreur. Un fichier retiré aujourd’hui peut rester connu par un cache, une archive ou un lien externe.
robots.txt indique aux robots coopératifs ce qu’ils ne devraient pas parcourir; il ne protège pas un secret. Mentionner un chemin sensible dans ce fichier peut même le rendre plus facile à deviner. Une donnée privée doit être retirée de la racine publique et protégée par un vrai contrôle d’accès.
Cartographier les points d’entrée
Regardez notamment
- Authentification connexion, récupération de compte, espace client et administration.
- Entrées utilisateur formulaires, recherche, téléversement, commentaires et paramètres d’URL.
- Interfaces machine API, webhooks, flux, XML-RPC ou endpoints utilisés par des intégrations.
- Sous-domaines staging, ancien site, portail, messagerie et outils internes rendus publics.
- Services tiers widgets et scripts qui reçoivent des données ou agissent avec votre domaine.
Une route visible n’est pas forcément vulnérable. L’inventaire sert à vérifier que chaque entrée est voulue, maintenue et protégée selon ce qu’elle permet de faire.
Les expositions qui demandent une action directe
Une sauvegarde téléchargeable, un fichier de configuration, une clé, un journal contenant des données personnelles, une carte source révélant du code interne ou un répertoire listé publiquement sont des preuves concrètes. Retirez l’accès, évaluez ce qui a été exposé et remplacez les secrets concernés.
Les pages d’erreur méritent aussi une vérification : elles devraient aider le visiteur sans afficher de trace, de chemin local, de requête ou de détail de base de données.
Attention
Si un secret a été servi publiquement, le supprimer ne suffit pas. Considérez-le comme divulgué, révoquez-le ou remplacez-le, puis vérifiez les journaux disponibles.
Donner un chemin de signalement avec security.txt
RFC 9116 définit un fichier security.txt à l’emplacement /.well-known/security.txt. Il peut indiquer un contact, une date d’expiration, une politique et d’autres renseignements utiles aux personnes qui découvrent un problème.
Ce fichier ne protège rien à lui seul. Il réduit la friction du signalement et évite qu’une information sensible soit envoyée au hasard. Le contact doit être surveillé et le fichier renouvelé avant son expiration.
Vérifier sans transformer un indice en faille
-
Observer
réponse HTTP, DNS, certificat, HTML, ressources et chemins que le site publie.
-
Attribuer
relier chaque élément à un propriétaire et à un besoin réel.
-
Confirmer
reproduire l’accès et distinguer une information publique d’une donnée qui devait rester privée.
-
Prioriser
selon l’accès obtenu, les données, la facilité et la possibilité d’abus.
-
Corriger et retester
retirer, protéger, mettre à jour ou réduire l’information, puis confirmer le résultat.
À retenir
Un bon constat dit ce qui est accessible, comment on le sait et ce que cela permet. Il évite les suppositions sur une compromission.
Questions fréquentes
Afficher la version du serveur est-il une faille ?
C’est une divulgation d’information et un indice de reconnaissance. Elle devient plus importante si la version est réellement vulnérable. Masquer l’indice ne remplace jamais la mise à jour.
robots.txt peut-il protéger un dossier privé ?
Non. Il s’agit d’une consigne pour les robots coopératifs, pas d’un contrôle d’accès. Retirez le contenu privé de la racine publique ou protégez-le par authentification.
Puis-je faire ces vérifications sur n’importe quel site ?
Restez sur les informations publiquement servies et obtenez une autorisation explicite avant tout test actif, automatisé ou susceptible d’affecter le service. Sur votre propre site, définissez aussi une limite et un plan de retour.
Vous voulez connaître votre surface publique réelle ?
Un audit externe peut distinguer les indices bénins, les fichiers exposés et les points d’entrée qui demandent une correction.
Demander un audit Commencer par les contrôles autonomes