Modèle de menaces

Frontmail vous permet d’envoyer des e-mails directement depuis le navigateur. C’est pratique, mais cela signifie qu’une partie de votre intégration se trouve dans du code que tout le monde peut lire et copier. Cette page recense toutes les attaques que nous connaissons contre ce modèle, la façon dont Frontmail s’en défend, ce que vous devez configurer vous-même et – en toute transparence – le risque qui subsiste. S’il manque quelque chose, écrivez à security@frontmail.dev.

Le modèle de base

• La clé publique est publique. Elle figure dans le code source de votre page. Traitez-la comme un nom d’utilisateur, pas comme un mot de passe. N’importe qui peut la copier et appeler l’API depuis un script.
• L’en-tête Origin n’est pas une authentification. Les navigateurs le renseignent honnêtement, mais un script peut envoyer n’importe quelle valeur. Les domaines autorisés empêchent d’autres sites d’utiliser votre clé dans le navigateur de leurs visiteurs – ils n’arrêtent pas un attaquant déterminé.
• Ce qui vous protège vraiment, c’est ce que l’attaquant ne peut pas modifier :
  1. le modèle – l’attaquant ne peut envoyer que vos modèles et seulement en remplir les paramètres,
  2. le CAPTCHA (Turnstile) – chaque envoi exige une résolution comparable à celle d’un humain,
  3. les limites – par IP, par clé, par organisation, par destinataire, et vos crédits.
• La clé privée est un secret. Sa place est uniquement sur votre serveur. Elle contourne la liste des domaines autorisés et le CAPTCHA, et peut lire l’historique de vos messages.

Le reste de cette page découle de ces quatre points.

Attaques et défenses

1. Phishing depuis votre domaine (le plus important)

Attaque. Un modèle prend son destinataire dans les paramètres – réinitialisation de mot de passe, notification, confirmation d’inscription à une newsletter. L’attaquant copie votre clé publique et envoie ce modèle à une victime, en remplissant reset_url avec son propre site. L’e-mail provient de votre domaine, passe SPF et DKIM, ressemble exactement aux vôtres et renvoie vers l’attaquant.

Ce que fait Frontmail. Une requête avec clé publique vers un modèle à destinataire dynamique reçoit un contenu verrouillé :

• le CAPTCHA est obligatoire (dynamic_recipient_requires_captcha),
• chaque lien doit pointer vers vos domaines autorisés – les liens dans les attributs, le CSS, le texte brut (y compris un simple evil.com/login, que les clients de messagerie transforment en lien) et l’objet sont vérifiés, y compris les astuces comme https://you.com@evil.com, les barres obliques inverses, les domaines Unicode sosies et les caractères encodés (link_not_allowed),
• l’adresse d’expéditeur, le nom d’expéditeur et Reply-To ne peuvent pas venir des paramètres (dynamic_field_not_allowed),
• pas de paramètres HTML, paramètres texte de 500 caractères au maximum,
• chaque destinataire reçoit au maximum 5 e-mails de ce type par jour de votre organisation (réglable).

Tout est vérifié avant qu’un crédit soit consommé. Les réponses automatiques sont verrouillées de la même façon.

Ce que vous devez faire. Remplissez Sécurité → Domaines de liens autorisés si vos liens mènent ailleurs que sur le domaine de votre site. Configurez vos propres clés Turnstile. Les modèles que seul votre serveur envoie (confirmations de commande, réinitialisations de mot de passe générées par votre backend) doivent être envoyés avec la clé privée.

Risque résiduel. L’attaquant peut toujours envoyer votre e-mail légitime à un inconnu – par exemple « Confirmez votre inscription à la newsletter » avec un lien vers votre site. Il ne contient rien que l’attaquant contrôle, il ne peut donc pas servir au phishing, mais il peut importuner. La limite par destinataire et le CAPTCHA réduisent ce risque. Du texte brut sans lien (par exemple « appelez ce numéro ») dans un paramètre texte reste possible dans la limite de 500 caractères – limitez les paramètres texte dynamiques à ce dont l’e-mail a vraiment besoin.

2. Spam dans votre propre boîte

Attaque. Un script inonde le modèle de votre formulaire de contact de messages indésirables.

Ce que fait Frontmail. Limite par IP (par défaut 10 requêtes / 60 s, IPv6 compté par réseau /64), limites par clé et par organisation, détection des anomalies, vérifications côté serveur des navigateurs headless et de la liste de blocage, CAPTCHA optionnel par modèle.

Ce que vous devez faire. Activez Exiger un CAPTCHA (Turnstile) pour les formulaires publics. Utilisez la liste de blocage pour les valeurs de spam connues.

Risque résiduel. Sans CAPTCHA, un attaquant patient qui change d’adresse IP passe les limites. Avec le CAPTCHA, il doit payer un service de résolution pour chaque e-mail.

3. Appeler l’API depuis un script ou une fausse « application »

Attaque. L’attaquant envoie des requêtes sans navigateur, avec un Origin falsifié ou sans aucun Origin.

Ce que fait Frontmail. Les requêtes sans Origin ni Referer (typiques des scripts) sont refusées, sauf si vous avez activé Autoriser les applications mobiles – même lorsque votre liste de domaines autorisés est vide. Seules les organisations ayant activé cette option utilisent le CAPTCHA mobile partagé de Frontmail ; toutes les autres doivent passer votre propre widget Turnstile, et son jeton doit avoir été émis sur le domaine à l’origine de la requête.

Ce que vous devez faire. Laissez Autoriser les applications mobiles désactivé si vous n’avez pas d’application native. Le code côté serveur doit utiliser la clé privée.

Risque résiduel. Un Origin falsifié passe toujours la liste des domaines autorisés ; ce sont le CAPTCHA et les limites qui l’arrêtent (voir le point 2).

4. Épuiser vos crédits ou votre carte

Attaque. Avec votre clé publique, l’attaquant envoie autant d’e-mails que les limites le permettent pour consommer votre quota mensuel – et, s’il le pouvait, votre découvert et vos recharges automatiques.

Ce que fait Frontmail.

• Le trafic par clé publique n’utilise pas le découvert et ne déclenche pas la recharge automatique, sauf si vous l’autorisez explicitement (Facturation → Dépenses liées au trafic par clé publique).
• La file d’attente des e-mails retenus est plafonnée ; au-delà, les requêtes sont refusées au lieu d’être mises en attente, pour que des envois indésirables ne puissent pas manger les crédits que vous achèterez plus tard.
• La recharge automatique a un plafond mensuel de nombre et de montant.

Ce que vous devez faire. Gardez les réglages par défaut, utilisez le CAPTCHA, surveillez les e-mails d’alerte d’anomalie.

Risque résiduel. Votre quota habituel et vos packs de crédits peuvent toujours être consommés par des envois indésirables qui passent le CAPTCHA et les limites. Cela vous coûte des crédits, pas d’argent supplémentaire.

5. Bloquer votre formulaire pour les vrais visiteurs

Attaque. Une inondation bon marché de requêtes invalides épuise les limites de votre organisation, et les vrais visiteurs reçoivent 429.

Ce que fait Frontmail. Les limites à l’échelle de l’organisation et la détection des anomalies ne comptent que les requêtes qui ont passé les vérifications du modèle et du CAPTCHA ; avant cela, seules la limite par IP et une protection anti-inondation généreuse s’appliquent.

Risque résiduel. Une grosse inondation distribuée peut encore ralentir les choses ; le pare-feu en périphérie (WAF) en absorbe l’essentiel.

6. Contourner le pare-feu

Attaque. Appeler directement les serveurs de Frontmail au lieu de passer par le CDN, pour éviter le pare-feu applicatif web et falsifier l’adresse IP du client.

Ce que fait Frontmail. Les serveurs n’acceptent que les requêtes passées par notre CDN et ne font confiance qu’à l’adresse IP du client transmise par le CDN. Rien à configurer de votre côté.

7. Une clé privée divulguée

Attaque. La clé privée se retrouve dans le code du navigateur (souvent après une migration depuis EmailJS, dont l’accessToken est une clé privée) et quelqu’un la copie.

Ce que fait Frontmail. Les SDK navigateur refusent de fonctionner avec une clé privée (private_key_in_browser), et l’API refuse les requêtes avec clé privée provenant d’une page web, sauf si vous avez activé Autoriser les clés privées dans les navigateurs. Les clés privées ne sont stockées que sous forme de hash.

Ce que vous devez faire. Ne mettez jamais sk_… dans du code frontend ni dans des variables VITE_ / NEXT_PUBLIC_. En cas de fuite, renouvelez-la immédiatement.

Risque résiduel. Quiconque détient votre clé privée peut envoyer sans CAPTCHA et lire l’historique de vos messages (y compris les soumissions de formulaires). Protégez-la comme un mot de passe.

8. Pièces jointes dangereuses

Attaque. Vous envoyer, ou envoyer à un destinataire dynamique, un logiciel malveillant en pièce jointe.

Ce que fait Frontmail. Les pièces jointes depuis le navigateur sont désactivées, sauf si le modèle les autorise. Les exécutables, les scripts, le HTML/SVG, les images disque, les fichiers Office avec macros et les types similaires sont bloqués, y compris lorsqu’ils sont dissimulés derrière des astuces comme invoice.pdf.exe., des caractères de droite à gauche ou des caractères invisibles. Les uploads avec clé publique ont une limite de volume quotidienne.

Risque résiduel. Des documents ordinaires (PDF, DOCX) peuvent toujours contenir du contenu malveillant ; l’antivirus de votre client de messagerie est la dernière ligne de défense.

9. Injection de HTML ou de script dans l’e-mail

Attaque. Placer un <script>, des pixels de suivi ou un faux formulaire dans un paramètre.

Ce que fait Frontmail. Les paramètres sont toujours échappés en HTML (même avec {{{ }}}), les paramètres html sont nettoyés selon une liste blanche et ne peuvent pas s’échapper des attributs, les URL dangereuses sont neutralisées, les retours à la ligne sont supprimés des en-têtes (pas d’injection d’en-têtes), les clés de pollution de prototype sont ignorées.

10. Harceler une personne (mail bombing)

Attaque. Utiliser un modèle à destinataire dynamique pour envoyer de nombreux e-mails à une même adresse.

Ce que fait Frontmail. Limite quotidienne par destinataire (5 par défaut), partagée avec les réponses automatiques ; liste de suppression pour les adresses qui ont rebondi ou se sont plaintes.

11. Prendre le contrôle de votre compte du tableau de bord

Attaque. Deviner le mot de passe, voler une session, voler une boîte mail.

Ce que fait Frontmail. Limites de tentatives de connexion, authentification à deux facteurs imposée pour chaque méthode de connexion, liens de réinitialisation de mot de passe à usage unique qui déconnectent tous les appareils, changements d’e-mail confirmés depuis l’ancienne adresse, notifications de nouvel appareil, rôles avec le moindre privilège et journal d’audit.

Ce que vous devez faire. Activez la 2FA, donnez à vos collègues le rôle le plus restreint qui suffit.

12. Voler les soumissions de vos formulaires

Attaque. Lire l’historique des messages ou les fichiers d’autres personnes.

Ce que fait Frontmail. L’historique n’est lisible qu’avec la clé privée ou par les membres de votre organisation ; chaque consultation est limitée à votre organisation, y compris les fichiers joints aux modèles.

13. Événements de livraison falsifiés

Attaque. Envoyer de faux événements « rebond » ou « plainte » pour placer vos clients sur la liste de suppression.

Ce que fait Frontmail. Les webhooks des fournisseurs sont vérifiés par signature lorsque le fournisseur le permet, et toujours par un jeton secret dans l’URL ; un événement n’affecte que le destinataire réel d’un message.

Ce que vous devez faire. Configurez la clé de signature de votre fournisseur lorsqu’elle est proposée.

14. Un SDK compromis

Attaque. Du code malveillant dans le script chargé par votre site.

Ce que fait Frontmail. Les versions sont compilées sans secrets, publiées avec attestation de provenance, et les actions de CI sont épinglées à des versions exactes.

Ce que vous devez faire. Chargez le SDK depuis une URL versionnée avec un attribut integrity (voir SDK navigateur), ou intégrez le paquet npm à votre bundle.

15. Frontmail utilisé par des criminels

Attaque. Un site de phishing utilise son propre compte Frontmail pour s’envoyer des mots de passe volés – cela arrive à tous les services de ce type.

Ce que fait Frontmail. E-mail du propriétaire vérifié, surveillance du trafic inhabituel, suspension rapide des comptes signalés. Signalez les abus à abuse@frontmail.dev.

Ce qui reste entre vos mains – check-list

• Renseignez les Sites autorisés avec vos domaines.
• Ajoutez vos propres clés Turnstile et exigez le CAPTCHA sur les formulaires publics.
• N’utilisez un destinataire dynamique que là où c’est nécessaire ; renseignez les Domaines de liens autorisés.
• Laissez Autoriser les applications mobiles et Autoriser les clés privées dans les navigateurs désactivés si vous n’en avez pas besoin.
• Clé privée uniquement sur le serveur ; renouvelez-la au moindre doute.
• Laissez désactivés le découvert et la recharge automatique pour la clé publique (par défaut).
• Activez la 2FA pour tous les membres de votre équipe.
• Chargez le SDK depuis une version épinglée avec integrity.