# Le nom de ma boutique affiche du texte que je n’ai pas écrit

> Un fragment de code apparaît dans le pied de page, dans l’onglet du navigateur ou dans les e-mails de commande : la valeur de configuration qui porte le nom de la boutique a été modifiée directement en base de données, et elle sert de véhicule.

- Source canonique : [https://allaux.fr/securite/nom-de-ma-boutique-affiche-du-texte-inconnu](https://allaux.fr/securite/nom-de-ma-boutique-affiche-du-texte-inconnu)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Lisez la valeur de PS_SHOP_NAME directement dans la table ps_configuration, avec phpMyAdmin ou en SQL : le champ du back-office peut afficher une version filtrée alors que la base contient autre chose. Copiez la valeur telle quelle avant de la corriger, elle documente l’injection. Remettre le bon nom ne referme rien : l’écriture est venue d’un module tiers, qu’il faut identifier et mettre à jour.

## Un bug d’affichage qui n’en est pas un

Le symptôme est presque toujours décrit de la même façon : « il y a du charabia dans le pied de page », « l’onglet du navigateur affiche du code », « le nom de ma boutique est cassé dans les e-mails de commande ». Le réflexe habituel est de chercher une mauvaise traduction, un thème mal configuré, un caractère parti de travers pendant un import. Ce n’est presque jamais cela.

Le nom de la boutique n’est pas un texte du thème. C’est une valeur de configuration stockée en base de données, sous la clé PS_SHOP_NAME. La boutique la relit et la réaffiche à des dizaines d’endroits : en-tête, pied de page, titre de la page dans l’onglet du navigateur, e-mails transactionnels, factures, notifications internes. Une seule ligne en base, servie partout, et pas toujours traitée de la même manière selon l’endroit où elle réapparaît.

C’est ce qui en fait une cible utile pour un attaquant. Il n’a pas besoin de modifier un fichier du thème, ni de toucher au tunnel de commande, ni de laisser un fichier sur le serveur. Il écrit une fois dans une valeur de configuration, et son contenu est ensuite servi sur toutes les pages, à tous les visiteurs, y compris ceux qui sont en train de payer. Le texte bizarre que vous voyez dans le pied de page n’est pas le problème : c’est la partie visible d’une chaîne dont le reste est silencieux.

## Ce qui doit vous alerter

- Un fragment de balise ou de code visible dans le pied de page, là où le nom de la boutique s’affiche normalement.
- Le titre de l’onglet du navigateur qui contient un texte que vous n’avez jamais saisi.
- Le nom de la boutique déformé dans les e-mails de confirmation de commande ou sur les factures.
- Un champ « Nom de la boutique » qui paraît normal dans le back-office alors que le site public affiche autre chose.
- Un script que vous ne reconnaissez pas dans le code source des pages, y compris sur le tunnel de commande.
- Des clients qui signalent qu’on leur a demandé deux fois leurs informations de paiement.

## Ce que PrestaShop a documenté en janvier 2025

Le 22 janvier 2025, PrestaShop a publié une alerte officielle sur une vague d’attaques exploitant des failles d’injection SQL présentes dans des modules tiers, et non dans le cœur. Le mode opératoire décrit est exactement celui-ci : les attaquants insèrent du contenu malveillant dans la valeur de configuration PS_SHOP_NAME stockée en base ; cette valeur sert ensuite à charger du JavaScript non autorisé qui capture les saisies des clients. La vérification recommandée par PrestaShop est simple à énoncer : chercher un script ou un contenu inattendu dans la valeur PS_SHOP_NAME, en base de données.

Ce JavaScript n’est pas là pour dégrader l’affichage. Il est là pour lire ce que vos clients tapent dans le tunnel de commande : coordonnées, adresse, informations de paiement. Dans les campagnes les plus abouties, la surcouche est soignée : un faux formulaire de paiement s’affiche d’abord, le client saisit sa carte, puis le vrai formulaire lui redemande les mêmes informations. La plupart des clients acceptent cette double saisie et terminent leur commande sans se douter que les données ont déjà été volées. C’est pour cela que ce symptôme ne peut pas être traité comme un défaut cosmétique.

Côté correctifs, PrestaShop a publié une version corrigée du module officiel ps_contactinfo, la 3.3.3, compatible PrestaShop 1.7.2 et plus, avec l’avis GitHub GHSA-35pq-7pv2-2rfw. Les recommandations officielles ne s’arrêtent pas là : mettre à jour l’ensemble des modules natifs et tiers, utiliser un préfixe de base de données personnalisé plutôt que le préfixe par défaut, déployer un pare-feu applicatif, faire des sauvegardes régulières et suivre les avis de sécurité PrestaShop.

## Lecture seule : valeur réellement stockée en base

```
SELECT name, value FROM ps_configuration WHERE name = 'PS_SHOP_NAME';
```

## Pourquoi lire la valeur en base et pas seulement dans le back-office

La requête ci-dessus est une lecture, elle ne modifie rien. Le préfixe ps_ doit être remplacé par celui de votre installation : si vous avez suivi la recommandation d’un préfixe personnalisé, le nom de la table est différent chez vous.

Pourquoi passer par la base plutôt que par le champ du back-office ? Parce que le back-office affiche la valeur dans un formulaire, et qu’un formulaire échappe, tronque ou masque une partie de ce qu’il reçoit. Une valeur qui paraît normale dans un champ de saisie peut contenir bien autre chose une fois servie dans une page. La lecture en base vous donne la valeur brute, celle qui est réellement enregistrée, sans intermédiaire d’affichage. C’est la seule vérification qui tranche.

Le préfixe par défaut joue un rôle direct dans ce scénario. Une écriture qui vise une table doit connaître son nom. Avec le préfixe standard, ce nom est identique sur des centaines de milliers de boutiques : il n’y a rien à deviner, et une attaque écrite une fois s’applique partout sans adaptation. Changer le préfixe ne corrige aucune faille, ce n’est pas une protection en soi ; c’est ce que PrestaShop recommande précisément parce que cela supprime une facilité gratuite offerte aux attaques automatisées.

## Ce que je fais dans cet ordre

1. **Lire la valeur brute en base** — Avec la requête de lecture ci-dessus, adaptée à votre préfixe. Vous cherchez la présence d’un script ou d’un contenu inattendu dans la valeur, pas seulement un nom mal orthographié.
2. **Comparer avec ce que sert réellement la page publique** — Affichez le code source d’une page du site et regardez les endroits où le nom de la boutique est réaffiché : en-tête, pied de page, titre du document. Un écart entre la base et la page indique où la valeur est réinterprétée.
3. **Vérifier les fichiers du thème** — La valeur de configuration n’est pas le seul véhicule possible. Des balises de script peuvent aussi être injectées directement dans les fichiers du thème, en particulier dans les gabarits chargés sur toutes les pages. Comparez le thème avec une copie saine.
4. **Corriger la valeur, puis chercher l’écriture** — Rétablir un nom de boutique propre fait disparaître le symptôme en quelques minutes. Cela ne dit rien sur la façon dont la valeur a été écrite. Tant que le module qui a permis cette écriture est en place, la valeur peut être réécrite.
5. **Mettre à jour l’ensemble des modules** — C’est la première recommandation officielle : les modules natifs comme les modules tiers. Le module officiel ps_contactinfo dispose d’une version corrigée en 3.3.3, compatible PrestaShop 1.7.2 et plus.
6. **Traiter l’incident comme une possible violation de données** — Si du JavaScript non autorisé a été servi sur le tunnel de commande, des données clients ont pu être capturées. Cela relève des obligations de notification, et cela se documente : dates, pages concernées, durée d’exposition.

## Corriger la valeur ne corrige pas ce qui a permis de l’écrire

> C’est l’erreur que je vois le plus souvent sur ce symptôme. On remet un nom de boutique correct, le pied de page redevient propre, le dossier est considéré comme clos. Mais l’écriture est venue de quelque part : une faille d’injection SQL dans un module, selon le mode opératoire décrit par PrestaShop en janvier 2025. Tant que ce module reste installé dans une version vulnérable, rien n’empêche la même écriture de se reproduire, avec un contenu différent et parfois moins visible.

## Pour aller plus loin

- **Injections SQL expliquées** — Le mécanisme qui permet d’écrire dans une table de configuration depuis l’extérieur. ([/securite/injections-sql-expliquees](/securite/injections-sql-expliquees))
- **Vérifier si mon site est compromis** — Les autres endroits à contrôler quand une valeur en base a été modifiée. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Nettoyer un site infecté** — Ce qu’il faut retirer, et dans quel ordre, une fois la source identifiée. ([/securite/nettoyer-un-site-infecte](/securite/nettoyer-un-site-infecte))
- **Base de données** — Ce que contient la base d’une boutique et pourquoi la configuration y est stockée. ([/glossaire/base-de-donnees](/glossaire/base-de-donnees))

## FAQ

### Le champ paraît normal dans le back-office, est-ce que c’est bon signe ?

Non, ce n’est pas concluant. Le back-office affiche la valeur dans un formulaire qui peut l’échapper ou la tronquer. Seule une lecture directe en base vous donne la valeur brute, telle qu’elle est servie aux visiteurs.

### Je remets le bon nom de boutique et tout redevient normal, c’est réglé ?

Le symptôme disparaît, pas la cause. Le mode opératoire décrit par PrestaShop en janvier 2025 passe par une faille d’injection SQL dans un module tiers. Si ce module est toujours là dans une version vulnérable, la valeur peut être réécrite.

### Pourquoi viser le nom de la boutique plutôt qu’une page précise ?

Parce qu’il est réaffiché partout : en-tête, pied de page, titre de l’onglet, e-mails transactionnels, factures. Une seule écriture en base suffit pour que le contenu soit servi sur l’ensemble du site.

### Changer le préfixe de base de données protège-t-il vraiment ?

Ce n’est pas une protection en soi, aucune faille n’est corrigée par ce changement. C’est une recommandation officielle de PrestaShop parce que le préfixe par défaut rend le nom des tables identique partout, ce qui facilite les attaques automatisées.

### Mes clients sont-ils concernés ?

Si du JavaScript non autorisé a été chargé sur les pages de commande, il faut partir du principe que des saisies ont pu être capturées. C’est à traiter comme une possible violation de données, avec le registre et les notifications qui vont avec.