Maintenance et sécurité
Limiter le spam des formulaires WordPress sans bloquer les vrais contacts
Le spam reçu depuis un site WordPress peut venir d’un formulaire automatisé, d’une adresse publiée, d’un relais mal configuré ou d’un domaine usurpé. Ajouter un CAPTCHA partout sans diagnostic peut dégrader l’accessibilité sans résoudre la cause.
Ce que ce symptôme signifie réellement
Le champ expéditeur, les en-têtes du message et les journaux du formulaire permettent de distinguer une soumission réelle d’un courriel qui imite le domaine. Le volume, les champs remplis et le rythme donnent aussi des indices.
Une protection efficace combine validation côté serveur, limitation proportionnée, pièges non intrusifs, réputation d’envoi et observation des faux positifs.
Avant toute modification : préserver les preuves et le retour arrière
Notez l’heure, l’URL, le message exact, le code HTTP et le dernier changement connu. Vérifiez ensuite qu’une sauvegarde récente couvre bien les fichiers et la base de données, qu’elle est lisible et qu’un retour arrière limité est possible. Une sauvegarde non testée ne suffit pas pour une intervention risquée.
- Ne transmettez jamais de mot de passe, clé privée, jeton, fichier
wp-config.phpou export de base dans un formulaire ou une capture. - Travaillez d’abord sur un staging ou une copie isolée lorsque le diagnostic exige une mise à jour, une modification de code ou une opération de base de données.
- Conservez les journaux et les fichiers suspects avant nettoyage : ils peuvent être nécessaires pour comprendre la cause ou vérifier l’étendue d’un incident.
Diagnostic : avancer du signal le plus fiable au test le moins intrusif
Conservez quelques exemples en supprimant les données personnelles inutiles. Relevez le formulaire, l’heure, l’adresse IP si sa conservation est légitime, le résultat anti-spam et la réponse du service d’envoi.
- Vérifier si le message correspond à une entrée réelle du formulaire ou seulement à une usurpation de l’adresse visible.
- Contrôler les validations côté serveur, les champs obligatoires, les limites de taille et l’absence d’URL libre dans des champs non prévus.
- Mesurer le taux de faux positifs avant et après chaque règle ; tester clavier, lecteur d’écran et mode sans JavaScript.
- Vérifier SPF, DKIM, DMARC, alignement du domaine et erreurs SMTP séparément du filtre anti-spam.
Correction : appliquer une action ciblée et réversible
Commencez par une règle ciblée sur le comportement observé. Une barrière invisible et mesurée est préférable à une énigme ou un blocage qui pénalise tous les visiteurs.
- Ajouter un honeypot accessible, une temporisation et une limite de fréquence côté serveur avec journalisation minimale.
- Refuser les formats impossibles et assainir toutes les données sans se fier uniquement au navigateur.
- Charger reCAPTCHA ou un tiers seulement sur les pages qui en ont besoin et selon le consentement applicable.
- Configurer l’envoi avec un domaine authentifié et un Reply-To distinct, puis surveiller rebonds et plaintes.
Contrôles après correction
Une page qui se recharge ne suffit pas à prouver que le problème est résolu. Contrôlez le parcours concerné, une page non connectée, l’administration, les erreurs console et réseau, les journaux serveur, le cache et les redirections. Vérifiez aussi les écrans mobile et desktop si le symptôme touchait le rendu.
- Soumissions légitimes reçues sur desktop et mobile sans obstacle clavier.
- Diminution du spam mesurée sans hausse des erreurs ni perte de contacts.
- Aucune donnée ou adresse sensible exposée dans le HTML, les journaux ou les messages.
Quand arrêter et demander une intervention
Si le formulaire crée des comptes, déclenche un paiement ou transmet des données sensibles, faites auditer la logique serveur et la délivrabilité avant d’ajouter des règles automatiques.
