Serveurs de préproduction et de test oubliés : la partie que personne ne surveille

Un serveur de préproduction ou de test oublié est une copie de votre site web ou de votre application mise en place pour le développement, puis laissée en ligne sur Internet. Il porte généralement un nom comme staging.yourcompany.com, dev.yourcompany.com ou test2.yourcompany.com, plus personne ne le vérifie, et il fait souvent tourner du code plus ancien avec des réglages plus faibles que la production.

Ces serveurs comptent parce qu'ils font partie de la présence de votre entreprise sur Internet, même si personne ne les traite ainsi. Ils ne reçoivent pas les mêmes mises à jour, connexions ni surveillance que le site principal, et pourtant ils partagent souvent les mêmes copies de base de données, clés d'API et comptes administrateur.

La bonne nouvelle : ils sont faciles à trouver et, une fois trouvés, la correction est généralement simple. Cet article montre comment les chercher et que faire de chacun.

Pourquoi les serveurs de préproduction sont oubliés

Un serveur de préproduction est créé pour une bonne raison : tester une version avant que les clients ne la voient. Puis la version est livrée, le développeur passe à un autre projet ou le contrat avec l'agence se termine, et le serveur continue de tourner parce que l'éteindre n'a jamais figuré sur la liste de tâches de personne. Les situations courantes :

• Une copie complète de la production, avec un export récent de la base de données, pour que les tests soient réalistes.
• Le mode débogage resté actif, qui affiche des traces d'erreur, des valeurs de configuration ou des détails du framework.
• Des mots de passe administrateur par défaut ou partagés, « juste pour les tests ».
• D'anciennes versions du CMS, des extensions ou des bibliothèques, mises à jour depuis en production.
• Pas de HTTPS, ou un certificat expiré depuis des mois.
• Une indexation par les moteurs de recherche jamais bloquée, si bien que le site de test apparaît à côté du vrai.

Rien de tout cela n'est spectaculaire en soi. Ensemble, cela donne un hôte sous votre propre domaine plus faible que tout ce qui l'entoure.

Comment ces serveurs deviennent visibles

Pas besoin de publier un lien pour qu'un hôte de préproduction soit trouvé. 3 voies courantes :

1. Certificate Transparency. Quand un certificat reconnu par les navigateurs est émis pour staging.yourcompany.com, le nom est inscrit dans des journaux ouverts (le protocole est décrit dans la RFC 9162). N'importe qui peut consulter ces journaux, comme expliqué dans les journaux Certificate Transparency expliqués.
2. Les enregistrements DNS. Un enregistrement qui pointe encore vers le serveur le rend joignable par son nom, et les noms faciles à deviner comme dev, test et beta sont essayés en premier.
3. Les moteurs de recherche et les archives. Un site de test sans règles d'indexation peut apparaître dans les résultats de recherche, et les anciennes pages restent dans les archives du web.

Comment trouver vos propres serveurs oubliés

Commencez par les noms, puis vérifiez chacun.

1. Cherchez %.yourcompany.com sur crt.sh et rassemblez tous les noms d'hôtes.
2. Parcourez votre zone DNS à la recherche de noms comme dev, stage, staging, test, uat, beta, old, demo, preview.
3. Résolvez chacun et vérifiez la réponse :

dig +short staging.yourcompany.com
curl -sI https://staging.yourcompany.com

1. Ouvrez chaque hôte dans un navigateur et demandez-vous : affiche-t-il de vraies données clients, un formulaire de connexion, une page de débogage, une page de serveur par défaut ou une erreur d'une plateforme d'hébergement ?
2. Cherchez les fichiers qui ne devraient jamais être servis. Le guide de test de l'OWASP traite ce point dans WSTG-CONF-04, en notant que les fichiers de sauvegarde sont souvent servis en texte brut au lieu d'être exécutés. Notre article sur les fichiers .env, .git et sauvegardes exposés liste les noms habituels.

Si un nom pointe vers une plateforme d'hébergement qui affiche une page « no such app » ou « bucket not found », traitez-le en urgence : c'est le scénario classique de prise de contrôle de sous-domaine.

Que faire de chacun

Pour chaque hôte de préproduction ou de test, choisissez l'une des 3 issues.

Le supprimer. Si personne ne peut nommer son responsable et son usage, arrêtez le serveur et supprimez l'enregistrement DNS. Supprimez l'enregistrement après le serveur, pas avant, et ne laissez jamais un CNAME pointer vers un service que vous ne payez plus.

Le restreindre. Si l'équipe en a encore besoin, placez-le derrière une authentification ou une liste d'IP autorisées. L'authentification HTTP Basic s'ajoute rapidement, mais MDN rappelle qu'elle doit être utilisée sur HTTPS, car les identifiants ne sont qu'encodés en base64. Un VPN ou un proxy tenant compte de l'identité est un meilleur choix à long terme.

Le nettoyer. La préproduction ne doit pas contenir de vraies données clients. Utilisez des données générées ou masquées, des clés d'API distinctes aux droits limités, et désactivez l'affichage de débogage.

Tenir les moteurs de recherche à l'écart est utile, mais ce n'est pas une protection. Google présente noindex comme un moyen d'exclure des pages des résultats, via <meta name="robots" content="noindex"> ou un en-tête X-Robots-Tag (Google Search Central). La page reste joignable par quiconque connaît l'adresse.

X-Robots-Tag: noindex

Une courte liste de contrôle

• Chaque hôte hors production a un responsable nommé et une date de fin.
• Aucune vraie donnée client en préproduction.
• La préproduction exige une connexion ou se trouve derrière un VPN.
• Mode débogage désactivé, clés distinctes, pas de mots de passe administrateur partagés.
• Certificat valide, ou l'hôte est supprimé.
• Enregistrements DNS supprimés en même temps que le serveur.
• La liste est revue à la fin de chaque projet, pas une fois par an.

La place de Datahorses

Datahorses surveille votre entreprise depuis l'extérieur chaque jour, y compris les nouveaux noms d'hôtes sous vos domaines, les sous-domaines et serveurs de test oubliés, et les fichiers exposés qu'ils hébergent. Chaque constat est accompagné d'étapes précises pour votre développeur, et nous n'entrons pas dans vos systèmes ni ne demandons le moindre accès. Voir ce que nous surveillons et ce qui se passe quand nous trouvons quelque chose.