WebBlocks CMS fournit une chaîne de protection locale unique pour les formulaires destinés aux visiteurs. Les blocs natifs Contact Form et Comments l’utilisent directement, et des plugins tels que WebBlocks Forms résolvent le même service depuis le conteneur du CMS. Les signaux suivent ainsi un site d’un type de formulaire à l’autre, au lieu que chaque formulaire assure sa défense de manière isolée.

Cette chaîne n’effectue aucune requête réseau et ne nécessite ni CAPTCHA, ni clé API, ni démon, ni service d’empreinte de navigateur, ni extension PHP facultative, ni produit de modération tiers. Elle utilise la base de données de l’application, le cache Laravel configuré et APP_KEY.

La protection repose délibérément sur plusieurs couches :

1. La validation Laravel et la protection CSRF rejettent normalement les requêtes mal formées ou provenant d’une autre origine.
2. Le moteur de rendu fournit une identité de formulaire signée, un horodatage et un champ piège généré.
3. Une preuve non valide, un champ piège rempli ou une soumission effectuée avant le délai minimal du formulaire emprunte le parcours de réussite générique, sans stockage ni livraison.
4. Les soumissions valides reçoivent un score fondé sur des signaux liés au contenu, au délai, à la répétition, à l’expéditeur, à la source, au préfixe réseau, au formulaire et à la réputation acquise.
5. Le score produit une décision allow, quarantine ou spam.
6. Le formulaire propriétaire stocke l’enregistrement à examiner ; seule la décision allow peut exécuter les actions de livraison.

Les visiteurs ne reçoivent jamais le score, les motifs, le résultat de la notification ni la confirmation qu’un piège les a reconnus. La réponse générique empêche les robots d’utiliser le point de terminaison pour ajuster leurs charges utiles.

inspect() renvoie score, des reasons uniques, decision et l’indicateur de compatibilité is_spam. Les seuils par défaut sont :

Pour Contact Messages, la quarantaine et le spam suppriment la notification par e-mail. Pour WebBlocks Forms, ils suppriment toutes les actions, notamment la notification métier, la réponse automatique, le webhook et l’intégration facultative à Campaigns. Les commentaires ne sont jamais publiés automatiquement : les commentaires légitimes et mis en quarantaine restent en attente, tandis qu’une décision de spam les stocke comme spam.

Les signaux sont additifs et le score final est plafonné à 100. Plusieurs signaux faibles peuvent donc placer une requête en quarantaine sans dépendre d’une seule règle fragile fondée sur un mot-clé.

Les adresses e-mail sont supprimées avant le calcul de l’empreinte du contenu. La rotation des expéditeurs ne masque donc pas un message répété, et le changement d’une adresse ne crée pas une nouvelle copie de campagne.

Chaque compteur et chaque recherche de réputation sont limités au site concerné. L’activité sur un site hébergé ne peut pas augmenter le score d’un autre site.

• Les clés de cache relatives à l’adresse IP exacte, à l’expéditeur, au contenu, au formulaire et au réseau utilisent un HMAC avec clé ; les valeurs soumises n’apparaissent pas dans les clés de cache.
• Les adresses IPv4 sont réduites à /24 et les adresses IPv6 à /64 avant le HMAC du préfixe réseau. Cela détecte les hôtes changeants sans stocker l’adresse ni recourir à la géolocalisation.
• Les seuils réseau sont supérieurs aux seuils d’adresse IP exacte afin de ne pas pénaliser trop tôt les bureaux, écoles, passerelles d’opérateurs et autres réseaux partagés.
• Les lignes de similarité contiennent un HMAC exact, un SimHash de 64 bits, des compteurs et des horodatages, et non le message soumis.
• Les métriques quotidiennes ne contiennent que le site, la date, la surface et les nombres agrégés de décisions.

La table de soumissions propriétaire peut néanmoins stocker les informations nécessaires à son produit ; par exemple, un Contact Message stocke l’adresse fournie par le visiteur et les détails de la source. Cet enregistrement produit est distinct de la réputation de protection et des métriques.

wbcms_submission_fingerprints conserve une réputation locale limitée au site. Les correspondances exactes ont l’effet le plus marqué ; les quasi-doublons utilisent une comparaison SimHash bornée sur, au maximum, les 200 empreintes vues le plus récemment au cours des 90 jours précédents.

Le marquage comme spam d’un Contact Message ou d’une soumission WebBlocks Forms enregistre un retour spam. Le rétablissement d’un élément indésirable ou mis en quarantaine à l’état New, Read ou Replied enregistre un retour ham et compense les faux positifs ultérieurs. L’archivage sert uniquement à l’organisation et n’enseigne rien. Le retour ne concerne que les soumissions ultérieures ; il ne reclasse pas rétroactivement les enregistrements existants.

Les plugins appellent recordOutcome($siteId, $validatedAnswers, 'spam') ou utilisent ham pour une correction.

Chaque soumission évaluée incrémente une ligne dans wbcms_submission_daily_totals pour son site, sa date et sa surface. Contact Messages affiche le récapitulatif glissant pour tous les sites auxquels l’administrateur connecté peut accéder. WebBlocks Forms l’affiche pour le site sélectionné.

• Vérifiées : toutes les soumissions valides ayant atteint le calcul du score ;
• Autorisées : la livraison normale a été permise ;
• Mises en quarantaine : stockées pour examen, avec livraison supprimée ;
• Spam : stockées comme spam, avec livraison supprimée.

Les requêtes écartées par un piège ou soumises trop rapidement n’atteignent jamais le calcul du score, ne sont pas stockées et ne figurent pas dans ces totaux. Le récapitulatif fournit un contexte opérationnel, et non un nombre de visiteurs ou un rapport de précision. summary($siteIds, $days) renvoie des zéros tant que la table des métriques n’est pas installée, ce qui protège les écrans des plugins pendant une mise à jour incomplète.

Tous les paramètres sont des substitutions facultatives par variables d’environnement. Les valeurs par défaut sont prudentes.

Maintenez le seuil de quarantaine en dessous du seuil de spam, chaque premier seuil de rafale en dessous du second, et utilisez des fenêtres positives. Après avoir modifié les variables d’environnement sur une installation dont la configuration est mise en cache, exécutez php artisan optimize:clear.

SubmissionProof lie ses valeurs à la fois à la surface et à l’identité du formulaire. Les moteurs de rendu envoient _form_stamp, _form_check_name et le champ vide renvoyé par fieldName($surface, $form). Les valeurs manquantes, modifiées, datées dans le futur ou provenant d’un autre formulaire entraînent un rejet sécurisé.

La preuve n’est pas un jeton à usage unique : les caches de pages complètes et les CDN peuvent servir le même formulaire à plusieurs visiteurs réels. Elle sert à lier le formulaire, à garantir son intégrité, à nommer le champ piège et à mesurer le temps écoulé, et non à empêcher la réutilisation.

Les plugins restent responsables de la validation, de l’autorisation, de la limitation du débit, du stockage, des noms d’état et du rendu. Un plugin compatible doit :

1. afficher une preuve signée et un champ piège généré vide ;
2. écarter silencieusement les preuves non valides, les pièges remplis et les soumissions inférieures à son minimum strict ;
3. transmettre uniquement les réponses validées à inspect() ;
4. utiliser le véritable ID du site et des identités stables de surface et de formulaire ;
5. conserver le score et les motifs avec sa soumission ;
6. exécuter les actions uniquement lorsque la décision est allow ;
7. envoyer les corrections spam/ham de l’opérateur à recordOutcome() ;
8. utiliser summary() au lieu d’interroger directement les tables de métriques du CMS.

Ne copiez pas le calculateur de score dans un plugin, n’affaiblissez pas les seuils communs à toute l’installation, n’exposez pas les codes de motif aux visiteurs et ne transmettez pas les réponses à un autre service. WebBlocks Forms constitue l’implémentation de référence.

• Examinez régulièrement la quarantaine et le spam ; la boucle d’apprentissage dépend de corrections d’état intentionnelles.
• Marquez les véritables campagnes comme Spam. Utilisez Archive uniquement pour le classement, car cet état n’entraîne pas la réputation.
• Rétablissez les faux positifs dans un état de flux de travail légitime.
• Ne modifiez les seuils qu’après avoir observé le trafic du site. Des nombres d’expéditeurs ou de réseaux plus faibles peuvent nuire au trafic provenant de bureaux partagés ou d’événements.
• Une hausse du nombre d’éléments Vérifiés sans e-mail dans la boîte de réception peut être normale lorsque la quarantaine ou le spam supprime la livraison. La notification et l’état éditorial restent distincts.
• Effectuez une sauvegarde avant de modifier APP_KEY. Une rotation rend les empreintes HMAC existantes et les clés de cache actives incomparables aux nouvelles jusqu’à l’expiration de l’influence des anciennes.

• Formulaires de contact et messages
• Commentaires et évaluations
• Sécurité
• Exploitation
• Système de plugins