187 règles de redirection : c’est le nombre que le fichier .htaccess hérité contenait encore, six mois après la bascule complète du site vers WordPress. Ce fichier n’avait jamais été nettoyé, seulement complété, migration après migration, depuis la plateforme d’origine.
Un développeur reprenant la maintenance du site a voulu comprendre pourquoi certaines requêtes anormales ciblaient des chemins en /account/ suivis d’identifiants numériques à six chiffres, un format totalement étranger à la structure WordPress en place. La réponse se trouvait dans ces règles de redirection jamais purgées.
Une plateforme fantôme toujours accessible
Avant sa migration vers WordPress, le site fonctionnait sur Squarespace. Lors du passage, une partie du contenu éditorial avait été reprise manuellement, mais certaines routes techniques héritées — en particulier celles liées à l’ancien espace membre — avaient été redirigées « pour éviter les erreurs 404 » plutôt que supprimées. Ces redirections pointaient vers des pages de connexion d’un sous-domaine Squarespace resté actif en arrière-plan, toujours lié au compte d’origine du client.
Le sous-domaine n’apparaissait dans aucun menu ni aucun lien visible du nouveau site. Il n’existait plus, du point de vue de l’éditeur, que dans la mémoire d’un fichier de configuration serveur. Pourtant, 47 identifiants de comptes suivant le format hérité répondaient encore avec un code 200 lorsqu’ils étaient interrogés directement.
Comment ces identifiants ont été retrouvés
L’examen des journaux d’accès a montré des requêtes automatisées testant des suites d’identifiants consécutifs sur ce même schéma d’URL, signe qu’un tiers avait déjà repéré la structure et tentait une énumération. Rien n’indiquait une intrusion réussie, mais la simple existence de cette surface accessible constituait déjà une exposition inacceptable, notamment parce que certains de ces comptes correspondaient à d’anciens collaborateurs du client n’ayant plus aucune raison d’y accéder.
- Le sous-domaine Squarespace restait résolu par le DNS du client, sans lien visible depuis WordPress.
- Les règles de redirection du
.htaccesspointaient explicitement vers ce sous-domaine. - Aucune procédure de désactivation de l’ancien abonnement n’avait été suivie lors de la migration.
Nettoyer, pas seulement rediriger
La correction a suivi trois étapes distinctes, dans un ordre précis : d’abord la révocation de l’ancien abonnement Squarespace auprès du client pour rendre le sous-domaine définitivement inaccessible, ensuite la suppression des règles de redirection obsolètes, enfin la mise en place de redirections propres uniquement vers des contenus qui existent réellement sur le nouveau site.
# Avant : redirection héritée vers l'ancienne plateforme
RewriteRule ^account/([0-9]{6})/?$ https://ancien-site.squarespace.com/account/$1 [R=301,L]
# Après : suppression pure et simple, remplacée par une 410 explicite
RewriteRule ^account/([0-9]{6})/?$ - [G]
Le code de statut 410 Gone plutôt qu’un 404 Not Found a été choisi volontairement : il indique aux robots d’indexation et aux outils d’audit que ces ressources ont été retirées de façon permanente et intentionnelle, ce qui accélère leur désindexation.
Un audit de redirections à part entière
Cette découverte a conduit à instaurer, pour tous les projets de migration suivants, une revue systématique des fichiers de réécriture existants avant toute reprise de développement. Un fichier .htaccess ou une configuration Nginx accumulée sur plusieurs années contient souvent des règles dont plus personne ne connaît l’origine ni la justification.
| Étape de l’audit | Objectif |
|---|---|
| Lister toutes les règles actives | Identifier chaque cible, interne ou externe |
| Tester la résolution de chaque cible | Détecter les domaines encore actifs à tort |
| Confirmer la fermeture des comptes tiers | Éliminer les accès résiduels sur l’ancienne plateforme |
| Remplacer par des règles minimales et documentées | Réduire la surface de configuration héritée |
La responsabilité ne s’arrête pas au contenu éditorial
Une migration de site est trop souvent pensée uniquement en termes de contenu : articles, pages, médias. Les éléments d’infrastructure — comptes, sous-domaines, jetons d’API, redirections — appartiennent à un périmètre distinct, souvent négligé parce qu’il ne se voit pas dans l’interface d’administration du nouveau site.
Conseil retenu depuis cet incident : toute migration se termine par une checklist de fermeture de l’ancienne plateforme, pas seulement par la bascule DNS vers la nouvelle.
Pour aller plus loin
Ce cas illustre un principe simple mais rarement formalisé : un site migré n’est réellement sécurisé que lorsque son ancienne version cesse d’exister, pas seulement lorsqu’elle cesse d’être visible. Un DNS actif, un abonnement non résilié ou une redirection oubliée suffisent à maintenir une porte ouverte sur une plateforme que plus personne ne surveille.
