blockHeadless et liste de blocage

En plus des domaines autorisés et de Turnstile, Frontmail propose deux filtres légers que vous pouvez activer dans le SDK, dans le tableau de bord, ou les deux. Les réglages du tableau de bord se trouvent sur la page Sécurité (les propriétaires et les administrateurs peuvent les modifier).

blockHeadless

Refuse les envois provenant de navigateurs automatisés « headless » (Puppeteer, Playwright, Selenium et similaires), souvent utilisés par les bots de spam de formulaires.

init({ publicKey: 'pk_4f2a…', blockHeadless: true });

Dans le SDK, la vérification a lieu dans le navigateur avant toute requête : send() échoue avec une BlockedError de code headless_blocked. Aucune requête, aucun crédit.
Dans Sécurité → Protection contre les abus → Bloquer les navigateurs headless, l’API refuse aussi les requêtes avec clé publique dont le user agent identifie un navigateur headless ou automatisé (HeadlessChrome, Puppeteer, Playwright, Selenium, PhantomJS, jsdom…). Utilisez les deux.

Les utilisateurs légitimes ne sont pas concernés. Vos propres tests de bout en bout, si – envoyez avec une clé privée dans les tests, ou désactivez l’option sur les environnements de test.

Liste de blocage

Une liste de blocage refuse les envois dont le destinataire – ou la valeur d’un paramètre choisi – correspond à une entrée. Usages typiques : l’adresse d’un spammeur persistant, des domaines d’adresses jetables, un concurrent qui aspire vos formulaires.

init({
  publicKey: 'pk_4f2a…',
  blockList: {
    list: ['spam@example.net', 'mailinator.com'],
    watchVariable: 'email', // paramètre ou champ de formulaire à vérifier
  },
});

Les valeurs sont comparées sans tenir compte de la casse, après suppression des espaces en début et en fin. Une entrée sans @ (ou commençant par @, comme @mailinator.com) correspond à toutes les adresses de ce domaine ; les autres entrées correspondent exactement à une adresse e-mail ou à la valeur surveillée.
Dans le SDK, la vérification a lieu avant la requête ; une correspondance échoue avec une BlockedError de code recipient_blocked.
Dans Sécurité → Liste de blocage, les propriétaires et les administrateurs saisissent des Valeurs bloquées (une par ligne, jusqu’à 1 000) et, en option, un Paramètre à vérifier (p. ex. email ; les chemins avec points fonctionnent aussi). L’API applique la liste à chaque requête – clé publique ou privée, y compris les clients obsolètes ou les scripts qui n’utilisent pas le SDK – avant qu’un crédit soit consommé. Elle vérifie les destinataires rendus (To/CC/BCC) et la valeur du paramètre à vérifier.

La liste du SDK est visible dans le code source de votre page ; ne gardez les entrées sensibles que dans la liste du tableau de bord.

limitRate (limitation côté client)

Les SDK peuvent aussi empêcher un même navigateur d’envoyer trop souvent – par exemple un visiteur qui double-clique sur le bouton d’envoi :

init({ publicKey: 'pk_4f2a…', limitRate: { id: 'contact', throttle: 10_000 } });

Un second envoi dans les 10 secondes depuis la même page (ou avec le même id) est refusé localement avec une BlockedError de code rate_limited. C’est un confort, pas une mesure de sécurité – voir Rate limits pour les limites côté serveur.

Paramètres stricts

Sécurité → Protection contre les abus → Paramètres stricts refuse les requêtes qui contiennent des paramètres non définis dans le schéma du modèle (voir Paramètres). Les bots qui remplissent tous les champs d’un formulaire, y compris des champs inventés, sont arrêtés avant de consommer des crédits.