phpBB Lab

Spam d’inscription phpBB : bloquer les faux comptes et spambots sans empêcher les vrais membres

Votre forum phpBB reçoit soudainement des dizaines, des centaines ou parfois des milliers de nouvelles inscriptions qui ne correspondent manifestement pas à de vrais membres ?

Vous observez des comptes avec :

• []des noms aléatoires ;
  []des profils remplis de liens publicitaires ;
  []des adresses e-mail suspectes ;
  []des messages identiques publiés dans plusieurs sujets ;
  []des signatures contenant des liens ;
  []des premiers messages sans rapport avec votre communauté ;
  []des inscriptions provenant continuellement de nouvelles adresses IP ;
  []des comptes créés automatiquement malgré un CAPTCHA.

Le problème peut rapidement devenir pénible pour une équipe d’administration.

Mais il faut distinguer deux phénomènes très différents.

Un robot qui parcourt votre forum pour lire des pages est un crawler.

Un robot qui remplit le formulaire d’inscription pour créer un compte est un spambot d’inscription.

Ce guide concerne principalement le deuxième cas.

L’objectif n’est pas de rendre l’inscription tellement compliquée qu’aucun véritable utilisateur ne puisse rejoindre votre communauté.

L’objectif est de construire plusieurs couches simples :

Empêcher les inscriptions automatisées faciles
↓
Limiter ce qu’un nouveau compte peut immédiatement faire
↓
Détecter rapidement les comptes suspects
↓
Supprimer le spam sans pénaliser les vrais membres

Une bonne protection anti-spam doit protéger le forum tout en restant :

• []accessible ;
  []compréhensible ;
  []rapide pour un humain ;
  []maintenable pour l’administrateur.

1. Commencez par identifier le type de spam

Tous les faux comptes ne fonctionnent pas de la même manière.

Vous pouvez rencontrer :

Cas A : inscriptions automatiques sans publication

Des centaines de comptes apparaissent mais ne publient jamais.

Cas B : inscription suivie immédiatement d’un message publicitaire

Exemple :

Inscription
↓
Premier message 30 secondes plus tard
↓
Lien commercial ou frauduleux

Cas C : inscription puis ajout d’un lien dans le profil

Le compte ne publie rien mais ajoute :

site web
signature
profil

dans l’espoir que ces pages soient indexées.

Cas D : spam publié plusieurs jours après l’inscription

Le compte semble normal au début puis commence à publier plus tard.

Cas E : comptes créés manuellement par de vraies personnes

Certaines campagnes de spam ne sont pas entièrement automatisées.

Un humain peut réellement :

• []lire votre CAPTCHA ;
  []répondre à une question ;
  []valider une adresse e-mail ;
  []puis utiliser le compte pour publier du spam.

Aucune protection CAPTCHA ne pourra arrêter à elle seule tous ces scénarios.

2. Vérifiez d’abord que les inscriptions viennent réellement de votre formulaire phpBB

Avant de modifier toute votre protection anti-spam, vérifiez que les comptes sont réellement créés par le processus normal d’inscription.

Posez-vous quelques questions :

• []les comptes apparaissent-ils dans la liste des membres ?
  []ont-ils une date d’inscription normale ?
  []apparaissent-ils dans les utilisateurs inactifs lorsqu’une activation est requise ?
  []les journaux montrent-ils quelque chose d’anormal ?
  []une extension externe crée-t-elle des comptes ?
  []votre forum utilise-t-il un SSO ou un système d’inscription externe ?

Si votre installation possède un système externe de création de comptes, le CAPTCHA natif de phpBB ne protège pas nécessairement cette autre porte d’entrée.

3. Vérifiez votre méthode actuelle de protection anti-spam

Dans le PCA, recherchez la rubrique consacrée aux :

Contre-mesures anti-spam

ou au libellé équivalent de votre traduction.

Vérifiez quelle méthode est réellement active.

Ne supposez pas qu’une protection est active simplement parce que vous l’avez configurée.

Effectuez une vraie inscription de test dans une fenêtre privée ou avec un navigateur déconnecté.

Vous devez voir exactement ce que voit un nouveau visiteur.

4. Les anciens CAPTCHA visuels ne constituent plus une protection suffisante

Les CAPTCHA basés uniquement sur des lettres déformées dans une image ont longtemps été utilisés sur les forums.

Le principe était simple :

Image difficile à lire
↓
L’humain reconnaît les caractères
↓
Le robot échoue

Cette approche possède aujourd’hui plusieurs problèmes.

• []la reconnaissance automatisée des images a énormément progressé ;
  []certains CAPTCHA visuels sont contournés depuis longtemps ;
  []augmenter toujours plus la déformation finit surtout par gêner les humains ;
  []ils posent de sérieux problèmes d’accessibilité.

Un CAPTCHA qui bloque un utilisateur malvoyant, aveugle, dyslexique ou ayant des difficultés cognitives tout en laissant passer des robots n’est pas une bonne protection.

Ne cherchez donc pas à rendre une image simplement de plus en plus illisible.

5. Le CAPTCHA Question/Réponse de phpBB

phpBB propose nativement une protection basée sur une question et une réponse.

Le principe est :

Question définie par l’administrateur
↓
Le visiteur répond
↓
phpBB compare la réponse
↓
Inscription autorisée ou refusée

Cette méthode peut rester utile si elle est correctement configurée.

Mais toute son efficacité dépend de la question choisie.

6. Une mauvaise question Question/Réponse

Évitez les questions universelles comme :

Combien font 2 + 2 ?

ou :

Quelle est la couleur du ciel ?

ou :

Quelle est la capitale de la France ?

Ces réponses peuvent être obtenues instantanément.

Une question dont la réponse apparaît immédiatement dans un moteur de recherche n’offre qu’une très faible protection.

7. Une meilleure question est liée à votre communauté

Une question plus intéressante peut demander une information simple pour un visiteur qui comprend le contexte du site.

Par exemple :

Quel mot apparaît en premier dans le titre de notre forum ?

ou une question liée au sujet réel de votre communauté.

L’objectif est de trouver une question :

• []simple pour un humain ;
  []non ambiguë ;
  []accessible sans vision ;
  []facile à comprendre ;

• dont la réponse n’est pas une connaissance générale universelle.

Évitez également les énigmes compliquées.

Le but n’est pas de tester l’intelligence de vos futurs membres.

8. Testez votre propre question avant de l’utiliser

Avant de l’activer, posez-vous cette question :

Un robot ou un moteur de recherche peut-il trouver immédiatement la réponse ?

Testez également la question avec quelqu’un qui ne connaît pas votre forum.

Une protection inutilement obscure peut créer plus de demandes de support que de bénéfices.

Votre question doit être :

facile pour un humain
+
moins évidente pour un robot

et non :

difficile pour tout le monde

9. Une question efficace aujourd’hui peut devenir inefficace demain

Si votre forum reçoit soudainement une nouvelle vague de spam après plusieurs mois de tranquillité, votre question a peut-être été apprise ou ajoutée à une base utilisée par les spambots.

Vous pouvez alors :

• []modifier la question ;
  []modifier la réponse ;
  []ajouter plusieurs questions ;
  []alterner les questions.

Ne gardez pas éternellement la même question simplement parce qu’elle fonctionnait parfaitement trois ans plus tôt.

10. Les outils automatisés modernes peuvent comprendre davantage de questions

Il faut également accepter une réalité :

les systèmes automatisés modernes ne se limitent plus à reconnaître quelques lettres dans une image.

Ils peuvent parfois :

• []analyser du texte ;
  []chercher une réponse sur le Web ;
  []traduire une question ;
  []interpréter des consignes.

La Question/Réponse reste donc une couche utile, mais elle ne doit pas être considérée comme une protection absolue.

La stratégie moderne consiste à utiliser plusieurs couches.

11. Le groupe « Nouveaux utilisateurs enregistrés » est extrêmement important

Empêcher 100 % des faux comptes est difficile.

Mais vous pouvez énormément réduire les dégâts causés par un compte qui réussit malgré tout à s’inscrire.

phpBB possède un groupe destiné aux nouveaux utilisateurs enregistrés.

L’idée est excellente :

Nouveau compte
↓
Permissions limitées
↓
Quelques participations légitimes
↓
Utilisateur normal

Ainsi, même si un spambot réussit son inscription, il ne dispose pas immédiatement de toutes les possibilités d’un membre établi.

12. Configurez une limite de nouveaux membres

Dans les paramètres d’inscription, phpBB permet de définir une limite de messages avant qu’un utilisateur ne sorte du statut de nouveau membre.

Par exemple :

Nouveau membre :
0 à 3 messages

Membre normal :
à partir du seuil configuré

Le nombre idéal dépend de votre communauté.

Un forum où chaque inscription est soigneusement vérifiée peut utiliser une stratégie différente d’un forum recevant plusieurs centaines de nouveaux membres chaque jour.

L’important est d’utiliser réellement ce groupe lorsque le spam constitue un problème.

13. Limitez ce qu’un nouveau compte peut faire

Selon votre organisation, vous pouvez configurer le groupe des nouveaux utilisateurs pour réduire certaines possibilités.

Par exemple :

• []limiter certaines actions ;
  []interdire ou restreindre certaines fonctionnalités non indispensables ;
  []empêcher l’utilisation immédiate de certaines signatures ; []imposer une modération des premiers messages dans certaines configurations ;

• réduire la possibilité d’utiliser certaines zones sensibles.

Ne bloquez pas inutilement tout.

Un vrai nouveau membre doit toujours pouvoir comprendre :

Je viens de m’inscrire, voici ce que je peux faire et comment participer normalement.

14. Les premiers messages sont votre meilleure zone de contrôle

La plupart des spambots cherchent à obtenir rapidement quelque chose :

• []publier un lien ;
  []ajouter un lien SEO ;
  []envoyer des messages privés ;
  []ajouter une signature ;

• faire la promotion d’un service.

Leurs premières actions sont donc particulièrement révélatrices.

Une stratégie efficace consiste à renforcer le contrôle pendant cette courte période au lieu d’imposer des restrictions permanentes à toute la communauté.

15. Modération des premiers messages

Pour une petite ou moyenne communauté, la validation des premiers messages peut être extrêmement efficace.

Le principe :

Inscription réussie
↓
Premier message
↓
Validation par un modérateur
↓
Participation normale ensuite

Un spambot peut réussir le CAPTCHA.

Mais son message publicitaire n’apparaît jamais publiquement.

Cette approche demande évidemment du travail humain.

Elle est donc particulièrement adaptée aux forums dont le nombre de nouvelles inscriptions reste raisonnable.

16. Activation par e-mail

phpBB peut demander à l’utilisateur d’activer son compte par e-mail.

Cela vérifie au minimum qu’il peut accéder à l’adresse indiquée.

Mais attention :

une adresse e-mail valide ne prouve pas que l’utilisateur est humain ou légitime.

Les spambots peuvent utiliser :

• []des comptes e-mail automatisés ;
  []des services temporaires ;

• des adresses réellement fonctionnelles.

L’activation par e-mail constitue une couche supplémentaire.

Elle ne remplace pas l’anti-spam.
17. Activation par administrateur

Pour une petite communauté privée ou très spécialisée, l’activation manuelle par un administrateur peut être extrêmement efficace.

Chaque inscription doit être approuvée avant que le compte devienne actif.

Avantages :

• []fort contrôle ;
  []très peu de faux comptes réellement actifs.

Inconvénients :

• []travail administratif ;
  []délai pour les vrais membres ;

• difficilement scalable sur une communauté très importante.

Ne choisissez pas cette méthode simplement parce que vous recevez trois spambots par semaine.

Adaptez la solution au volume réel.

18. N’utilisez pas le bannissement d’adresses IP comme protection principale

Un spambot peut aujourd’hui utiliser :

• []VPN ;
  []proxies ;
  []réseaux mobiles ;
  []botnets ;

• adresses IP changeantes.

Vous pouvez donc observer :

Compte spam 1 → IP A
Compte spam 2 → IP B
Compte spam 3 → IP C
Compte spam 4 → IP D

Bannir chaque adresse une par une devient rapidement inutile.

Le bannissement IP reste utile dans certains cas précis.

Mais il ne doit pas constituer votre principale stratégie anti-inscription.

19. Attention aux VPN

Un VPN n’est pas automatiquement utilisé par un spammeur.

De vrais utilisateurs utilisent des VPN pour :

• []la confidentialité ;
  []le travail ;
  []la sécurité ;
  []des raisons géographiques.

Bloquer tous les VPN peut donc éliminer des utilisateurs parfaitement légitimes.

Ne confondez pas :

IP différente

avec :

spammeur différent

et encore moins avec :

personne malveillante

20. Surveillez les domaines e-mail utilisés

Une campagne peut parfois utiliser massivement un même domaine.

Exemple :

user1@example-spam.tld
user2@example-spam.tld
user3@example-spam.tld

phpBB permet de bannir certaines adresses ou certains motifs d’adresses e-mail.

Cela peut être utile lorsqu’un domaine est clairement utilisé uniquement pour du spam sur votre forum.

Mais soyez prudent.

21. Ne bloquez pas Gmail, Outlook ou les grands fournisseurs

Vous pourriez constater que beaucoup de comptes spam utilisent :

@gmail.com

Cela ne signifie évidemment pas qu’il faut bannir Gmail.

Des millions de véritables utilisateurs utilisent ces fournisseurs.

Le blocage d’un domaine doit viser un domaine réellement problématique et suffisamment spécifique.

22. Les adresses e-mail temporaires

Certains spambots utilisent des services fournissant des adresses valables quelques minutes.

Cela leur permet de :

• []recevoir le message d’activation ;
  []activer le compte ;

• abandonner ensuite l’adresse.

Bloquer certains domaines temporaires peut aider.

Mais cela devient vite une course permanente :

Domaine bloqué
↓
Nouveau domaine créé
↓
Liste à mettre à jour

Utilisez donc cette méthode comme complément, pas comme défense unique.

23. Les profils peuvent être une cible même sans message

Certains faux comptes ne publient jamais.

Ils cherchent simplement à créer une page contenant :

• []un site Web ;
  []une signature ;
  []un champ personnalisé ;
  []du texte promotionnel.

Vérifiez donc les permissions et possibilités offertes aux nouveaux utilisateurs.

Un compte créé uniquement pour obtenir un lien public n’a plus beaucoup d’intérêt si ce lien n’est pas immédiatement disponible.

24. Surveillez également les messages privés

Un spammeur peut éviter les forums publics et utiliser les messages privés.

Les modérateurs ne voient alors pas immédiatement le contenu envoyé.

Si votre communauté subit ce type d’abus, examinez les permissions accordées aux nouveaux utilisateurs concernant les MP.

Une stratégie possible consiste à ne pas offrir immédiatement toutes les capacités de messagerie privée à un compte qui vient d’être créé.

Là encore, adaptez la restriction à votre communauté.

25. Ne rendez pas l’inscription hostile aux vrais humains

Une protection anti-spam peut être tellement agressive qu’elle provoque plus de dégâts que le spam lui-même.

Exemple :

CAPTCHA illisible
+
question incompréhensible
+
challenge JavaScript
+
validation e-mail
+
validation administrateur
+
attente de plusieurs heures

Le spambot abandonnera peut-être.

Le véritable utilisateur aussi.

Mesurez toujours le coût imposé à vos membres.

26. L’accessibilité doit faire partie de votre stratégie anti-spam

Un mécanisme de protection ne doit pas exclure :

• []les utilisateurs aveugles utilisant un lecteur d’écran ;
  []les utilisateurs malvoyants ;
  []les personnes utilisant uniquement le clavier ;
  []les utilisateurs présentant certaines difficultés cognitives ;

• les utilisateurs sur mobile.

Évitez notamment une protection reposant exclusivement sur :

Regardez cette image et recopiez les caractères.

Une bonne Question/Réponse textuelle simple peut être beaucoup plus accessible.

Si vous installez une extension anti-spam externe, testez réellement son formulaire avec :

• []clavier ;
  []mobile ;

• lecteur d’écran lorsque possible.

27. Le JavaScript seul ne constitue pas une protection suffisante

Certains systèmes reposent sur :

déplacement d’un curseur
case dynamique
bouton JavaScript
challenge exécuté dans le navigateur

Ces mécanismes peuvent ajouter une couche utile.

Mais un robot peut parfois envoyer directement une requête HTTP sans utiliser l’interface visible.

Un contrôle important doit donc être validé côté serveur.

La protection visuelle n’est pas la protection réelle.

28. Utiliser une extension anti-spam

Il existe des extensions phpBB proposant des protections supplémentaires.

Avant d’en installer une, vérifiez :

• []sa compatibilité avec votre version phpBB ;
  []sa maintenance récente ;
  []sa compatibilité PHP ;
  []son accessibilité ;
  []sa politique de confidentialité ;
  []si elle contacte un service externe ;

• ce qui se passe si ce service devient indisponible.

N’installez pas cinq extensions anti-spam simultanément.

Vous risquez de créer :

• []des conflits ;
  []des formulaires impossibles à utiliser ;

• des erreurs difficiles à diagnostiquer.

29. Protection locale ou service externe ?

Deux philosophies existent.

Protection locale

Le contrôle est effectué sur votre serveur.

Avantages :

• []pas de dépendance externe ;
  []meilleur contrôle des données ;

• pas de panne d’un fournisseur externe.

Service externe

La requête est analysée par un fournisseur.

Avantages potentiels :

• []détection plus évoluée ;
  []données provenant de nombreuses installations ;

• mise à jour centralisée des règles.

Mais vérifiez :

• []les données transmises ;
  []la conformité à votre politique de confidentialité ;
  []la disponibilité ;
  []les coûts ;

• l’accessibilité du challenge.

30. Cloudflare ou un proxy peuvent-ils arrêter le spam d’inscription ?

Un proxy peut aider à limiter certaines vagues automatisées avant qu’elles n’atteignent phpBB.

Il peut notamment appliquer selon ses fonctionnalités :

• []rate limiting ;
  []analyse du trafic ;
  []challenges ;
  []règles sur certaines URL.

Par exemple, une quantité extrêmement élevée de requêtes vers :

ucp.php?mode=register

peut être suspecte.

Mais attention :

ne bloquez pas simplement tous les accès à la page d’inscription.

Le but est précisément de laisser les vrais utilisateurs s’inscrire.

31. Le rate limiting peut réduire les attaques massives

Une personne humaine ne tente généralement pas de créer :

100 comptes par seconde

Si votre serveur reçoit ce type de trafic, une limitation au niveau du proxy ou du serveur peut être très utile.

Elle permet de réduire le coût avant que PHP et phpBB ne traitent toutes les requêtes.

Mais ne choisissez pas une valeur arbitraire trop agressive.

Plusieurs vrais utilisateurs peuvent partager la même IP derrière :

• []un opérateur mobile ;
  []une entreprise ;
  []une école ;
  []un NAT ;

• un VPN.

32. Vérifiez vos logs serveur

Sur un VPS, les journaux Apache ou Nginx peuvent montrer la fréquence des accès à la page d’inscription.

Cherchez notamment :

mode=register

et comparez avec votre trafic habituel.

Un pic de milliers de requêtes en quelques minutes peut indiquer une campagne automatisée.

Regardez également :

• []les IP ;
  []les User-Agent ;
  []la fréquence ;
  []les codes HTTP ;

• les heures.

33. Un User-Agent Chrome ne signifie pas qu’il s’agit d’un humain

Un spambot peut parfaitement envoyer :

Mozilla/5.0 … Chrome/…

Il ne faut donc jamais conclure :

Il indique Chrome, donc c’est un utilisateur réel.

Observez le comportement global.

34. Différence entre spam d’inscription et attaque de crawlers

Ne confondez pas :

GET de milliers de sujets

avec :

POST de milliers de formulaires d’inscription

Le premier problème concerne surtout le crawl.

Le deuxième concerne le processus d’inscription.

Les solutions peuvent être très différentes.

Un excellent

robots.txt

ne protège pas votre formulaire d’inscription contre un spambot qui l’ignore complètement.

35. L’activation administrateur n’est pas une protection du serveur

Imaginez :

10 000 inscriptions automatiques

avec activation administrateur.

Les comptes ne deviennent pas actifs.

C’est positif.

Mais le serveur doit tout de même :

• []recevoir les formulaires ;
  []traiter les données ;
  []créer les comptes inactifs ;
  []éventuellement envoyer des e-mails ;

• stocker les informations.

Vous risquez ensuite de devoir supprimer des milliers de comptes inactifs.

L’activation administrateur protège donc surtout la communauté.

Elle ne remplace pas le filtrage des inscriptions automatisées.

36. Nettoyer les faux comptes existants

Une fois la protection améliorée, vous pouvez traiter les comptes déjà créés.

Ne supprimez pas automatiquement :

tous les utilisateurs avec 0 message

Un vrai membre peut s’être inscrit pour lire le forum sans jamais avoir publié.

Utilisez plusieurs critères.

Par exemple :

• []date d’inscription ;
  []activation ;
  []adresse e-mail ;
  []pseudo ;
  []profil ;
  []site Web ;
  []signature ;
  []IP ;
  []activité ;
  []messages.

Plusieurs signaux concordants valent mieux qu’un seul.
37. Utilisateurs inactifs

Le PCA permet de gérer les utilisateurs inactifs.

Vous pouvez y trouver des comptes n’ayant jamais terminé leur activation.

Avant de nettoyer massivement, vérifiez :

• []la date ;
  []la raison de l’inactivité ;

• la configuration d’activation utilisée à l’époque.

Un véritable membre peut également être resté inactif parce que votre serveur e-mail ne lui a jamais envoyé son message d’activation.

38. Ne supprimez pas directement les faux utilisateurs avec SQL

Évitez :

DELETE FROM phpbb_users WHERE …

comme méthode normale de suppression des comptes.

Un utilisateur phpBB peut être référencé dans plusieurs tables.

La suppression native depuis le PCA utilise les mécanismes prévus par phpBB.

Une suppression SQL improvisée peut laisser :

• []des données orphelines ;
  []des relations incohérentes ;

• des informations non nettoyées.

Utilisez les fonctions phpBB prévues pour gérer les utilisateurs.

39. Supprimer les messages d’un spammeur

Lors de la suppression d’un compte, réfléchissez au devenir de ses messages.

Un spammeur peut avoir publié :

50 messages publicitaires

Vous ne voulez probablement pas conserver ces messages sous forme d’auteur « Invité ».

Vérifiez donc les options proposées lors de la suppression.

Attention à ne pas supprimer automatiquement les messages d’un compte si vous n’êtes pas certain qu’il s’agit d’un spammeur.

40. N’utilisez pas un seul indice pour automatiser une suppression

Exemple de mauvaise règle :

Pseudo contient des chiffres
= spam

Un vrai utilisateur peut parfaitement choisir :

Michel1975
FordMustang68
Runner2026

Autre mauvaise règle :

Compte avec 0 message
= spam

Ou :

Adresse Gmail
= spam

Une détection fiable doit croiser plusieurs signaux.

41. Pourquoi certains spambots reviennent après chaque changement de CAPTCHA ?

Vous modifiez votre CAPTCHA.

Le spam disparaît pendant trois jours.

Puis il recommence.

Ce scénario ne signifie pas forcément que le CAPTCHA ne fonctionne pas.

Le système utilisé par les spammeurs peut :

• []analyser votre nouveau formulaire ;
  []apprendre la nouvelle réponse ;
  []faire intervenir un humain ;
  []changer de méthode.

C’est pourquoi une protection uniquement basée sur un secret fixe finit souvent par perdre de son efficacité.

42. La meilleure défense est une combinaison de couches

Une stratégie raisonnable peut ressembler à :

Question/Réponse correctement choisie
↓
Activation e-mail
↓
Groupe Nouveaux utilisateurs enregistrés
↓
Permissions limitées au début
↓
Modération éventuelle des premiers messages
↓
Surveillance des inscriptions
↓
Filtrage serveur en cas de campagne massive

Aucune couche n’a besoin d’être parfaite.

Ensemble, elles rendent le spam beaucoup plus coûteux.

43. Exemple : petit forum associatif

Supposons :

5 nouvelles inscriptions par semaine

et quelques spambots.

Une stratégie possible :

• []Question/Réponse spécifique ;
  []activation par e-mail ;
  []groupe nouveaux utilisateurs ;
  []validation du premier message.

La charge de modération reste très faible.

44. Exemple : grande communauté publique

Supposons :

300 inscriptions légitimes par jour

L’activation manuelle par un administrateur devient probablement irréaliste.

Préférez :

• []protection anti-spam automatique solide ;
  []activation e-mail si adaptée ;
  []restrictions temporaires ;
  []détection comportementale ;
  []rate limiting contre les vagues massives ;
  []outils efficaces pour les modérateurs.

La stratégie dépend toujours du contexte.

45. Exemple de diagnostic d’une vague soudaine

Situation :

Avant :
3 faux comptes par semaine

Aujourd’hui :
400 comptes en 6 heures

Étape 1 :

Vérifiez que le CAPTCHA configuré est réellement affiché.

Étape 2 :

Testez volontairement une mauvaise réponse.

Le compte doit être refusé.

Étape 3 :

Examinez les IP et User-Agent.

Étape 4 :

Vérifiez si les comptes sont :

actifs
inactifs
avec messages
sans messages

Étape 5 :

Changez votre Question/Réponse si elle semble compromise.

Étape 6 :

Activez ou renforcez les limitations des nouveaux utilisateurs.

Étape 7 :

Si la fréquence des requêtes est énorme, ajoutez une limitation au niveau du serveur ou du proxy.

Étape 8 :

Mesurez les nouvelles inscriptions pendant plusieurs jours.

46. Comment savoir si votre protection fonctionne ?

Mesurez.

Avant :

150 faux comptes par jour
30 messages spam par jour
20 minutes de nettoyage quotidien

Après :

3 faux comptes par jour
0 message spam public
2 minutes de nettoyage

Vous avez obtenu un résultat utile même si trois comptes réussissent encore leur inscription.

L’objectif réaliste n’est pas nécessairement zéro tentative.

L’objectif est que les tentatives deviennent sans conséquence et faciles à gérer.

47. Ne jugez pas uniquement le nombre d’inscriptions bloquées

Une protection peut annoncer :

10 000 bots bloqués

mais empêcher simultanément 30 % de vos vrais utilisateurs de s’inscrire.

Ce serait une mauvaise protection.

Mesurez également :

• []les inscriptions légitimes ;
  []les demandes d’aide concernant l’inscription ;
  []les abandons ;
  []les problèmes d’accessibilité ;

• le nombre de faux positifs.

48. Testez vous-même l’inscription après chaque modification

Après tout changement :

1. []déconnectez-vous ;
   []ouvrez une fenêtre privée ;
   []ouvrez la page d’inscription ;
   []testez une mauvaise réponse ;
   []testez une bonne réponse ;
   []créez un compte de test ; []vérifiez l’e-mail ;
   []connectez-vous ;
   []vérifiez les permissions du nouveau compte ;
   []testez un premier message.

Ne considérez jamais une protection comme fonctionnelle simplement parce que le PCA affiche :

Activé

49. Informations à fournir lorsque vous demandez de l’aide

Indiquez :

Version phpBB :
Version PHP :
Type d’hébergement :
Méthode CAPTCHA :
Activation des comptes :
Nouvelle limite membre :
Extensions anti-spam :
Proxy/CDN :

Décrivez ensuite le problème :

Nombre habituel de faux comptes :
Nombre actuel :
Depuis quelle date :
Les comptes publient-ils :
Les comptes sont-ils activés :
Le CAPTCHA est-il réellement affiché :
Une mauvaise réponse bloque-t-elle l’inscription :

Ajoutez si possible :

• []quelques exemples de User-Agent sans données sensibles ;
  []la fréquence des requêtes d’inscription ;
  []les changements récents ;
  []les extensions récemment installées.

Ne publiez jamais :

• []mot de passe ;
  []cookie ;
  []clé API ;
  []clé privée ;
  []identifiants de base de données ;
  []secret utilisé par votre CAPTCHA externe.

50. Checklist anti-spam

• []J’ai vérifié quelle protection CAPTCHA est réellement active.
  []J’ai testé le formulaire comme un visiteur déconnecté.
  []Une mauvaise réponse empêche réellement l’inscription.
  []Ma Question/Réponse n’est pas une question générale triviale.
  []Ma question reste simple et accessible pour les humains.
  []Je n’utilise pas uniquement un CAPTCHA visuel difficile à lire.
  []J’utilise le groupe Nouveaux utilisateurs enregistrés lorsque pertinent.
  []Les nouveaux comptes n’obtiennent pas immédiatement des permissions inutiles.
  []J’ai réfléchi aux messages privés et signatures des nouveaux comptes.
  []J’ai choisi une méthode d’activation adaptée à mon volume.
  []Je ne compte pas uniquement sur les bannissements IP.
  []Je ne bloque pas tous les utilisateurs de VPN.
  []Je ne bloque pas les grands fournisseurs d’e-mail sans raison.
  []Je surveille les comptes inactifs.
  []Je supprime les utilisateurs via les outils phpBB plutôt que par SQL.
  []J’ai vérifié les logs lors d’une vague importante.
  []J’utilise un filtrage serveur ou proxy si le volume devient massif.
  []J’ai testé l’inscription sur mobile.
  []J’ai vérifié l’accessibilité.
  []J’ai mesuré les faux positifs.

À retenir

Le spam d’inscription ne se résout pas avec une seule case à cocher.

La stratégie la plus efficace consiste à protéger plusieurs étapes.

Avant l’inscription
→ CAPTCHA ou Question/Réponse adaptée

Pendant l’inscription
→ validation correcte côté serveur

Après l’inscription
→ groupe Nouveaux utilisateurs enregistrés

Premières actions
→ permissions limitées / modération lorsque nécessaire

Attaque massive
→ filtrage serveur ou proxy

Administration
→ surveillance et nettoyage propre

Retenez surtout :

un CAPTCHA visuel difficile à lire n’est pas automatiquement un bon CAPTCHA ;

une Question/Réponse triviale peut être contournée très facilement ;

une adresse e-mail validée ne prouve pas qu’un compte est légitime ;

un VPN ne signifie pas automatiquement spam ;

une énorme liste d’IP bannies ne remplace pas une vraie stratégie anti-spam ;

et empêcher l’inscription de vrais utilisateurs n’est pas une victoire contre les robots.

La meilleure protection est celle qui rend le spam difficile et peu rentable tout en gardant l’inscription simple, accessible et compréhensible pour les véritables membres.