Injection SQL : ce qui a pu être lu, et ce qu'il faut figer
Une injection SQL ne se voit pas toujours sur la page d'accueil. Elle se lit dans des contenus modifiés, des comptes créés, ou des données clientes qui n'auraient jamais dû sortir.
1. Signes côté contenu et comptes
Textes de pages farcis de liens, utilisateurs administrateurs nés en base, options de site réécrites, articles datés dans le futur. Le fichier PHP peut être intact : c'est la base qui a été écrite.
2. Ne restaurez pas la base trop tôt
Une sauvegarde d'il y a trois semaines contient parfois déjà l'injection, et vous perdez les commandes récentes. Copiez d'abord l'état actuel. On compare ensuite, on ne remplace pas à l'aveugle.
3. Identifiez la requête d'entrée
Formulaire, filtre d'URL, module de recherche, API mal protégée. Sans trouver le paramètre exploité, une nouvelle écriture aura lieu dès qu'un bot rejouera la requête — ce qu'ils font en boucle.
4. Données potentiellement lues
Même si rien n'a été affiché publiquement, une injection peut extraire des emails, des hashs, des commandes. Le constat doit dire si une exfiltration est plausible, pour décider d'une notification.
5. Corrigez l'entrée, pas seulement les lignes sales
Retirer les spams en base sans corriger le code laisse la porte ouverte. Mise à jour du composant, requêtes préparées, comptes régénérés : le nettoyage visible n'est que la moitié.