Domaines autorisés

Les domaines autorisés (une liste blanche de domaines) garantissent que votre clé publique ne fonctionne que sur vos propres sites. Chaque requête avec la clé publique est comparée à la liste à l’aide de l’en-tête Origin du navigateur (ou de Referer si Origin est absent). Les requêtes provenant d’autres origines sont refusées avec 403 origin_not_allowed et ne consomment aucun crédit.

Les domaines autorisés sont disponibles dans tous les forfaits, y compris Free.

Configuration

Les propriétaires et les administrateurs ajoutent des entrées dans Sécurité → Sites autorisés : saisissez un domaine, cliquez sur Ajouter (une entrée à la fois, jusqu’à 100) et enregistrez. Les entrées sont comparées à l’hôte de l’origine de la requête ; le schéma (http/https) ne compte pas.

Entrée	Correspond à
example.com	https://example.com et http://example.com sur n’importe quel port – mais pas www.example.com
*.example.com	n’importe quel sous-domaine : www.example.com, shop.eu.example.com – mais pas example.com lui-même
localhost	développement local sur n’importe quel port
localhost:3000	uniquement ce port
127.0.0.1	développement local via l’adresse IP
my-app.pages.dev	déploiements de prévisualisation chez un hébergeur

Ajoutez à la fois example.com et *.example.com si vous avez besoin du domaine principal et des sous-domaines.

Attention

Une liste vide autorise n’importe quelle origine web. Le tableau de bord vous en avertit (Aucun domaine défini – n’importe quel site peut utiliser votre clé publique) ; ne passez pas en production sans y avoir mis au moins votre domaine de production. Les requêtes sans en-tête Origin ni Referer (serveurs, curl, applications natives) sont refusées que la liste soit vide ou non – sauf si vous autorisez les applications mobiles.

Applications mobiles

Les applications natives (React Native, Flutter, Swift, Kotlin) n’envoient ni Origin ni Referer, l’API publique les refuse donc par défaut (comme EmailJS, qui bloque les requêtes hors navigateur tant que vous ne les autorisez pas). Pour envoyer depuis une application avec la clé publique, activez Sécurité → Applications mobiles → Autoriser les applications mobiles (désactivé par défaut) et cliquez sur Enregistrer. Ensuite :

Requête	Applications mobiles désactivées, liste vide	Applications mobiles désactivées, liste remplie	Applications mobiles activées, liste vide	Applications mobiles activées, liste remplie
Origin / Referer dans la liste	acceptée	acceptée	acceptée	acceptée
Origin / Referer absent de la liste	acceptée	403 origin_not_allowed	acceptée	403 origin_not_allowed
ni Origin ni Referer (application native, serveur, curl)	403 origin_not_allowed	403 origin_not_allowed	acceptée	acceptée
Origin: null	acceptée	403 origin_not_allowed	acceptée	403 origin_not_allowed

L’erreur d’une requête sans Origin contient details.reason: "no_origin". L’autorisation des applications mobiles détermine aussi quelle clé CAPTCHA vérifie ces requêtes : ce n’est qu’avec l’option activée qu’elles sont vérifiées avec le widget mobile partagé de Frontmail (voir Turnstile).

Modifié en septembre 2026

Auparavant, une liste vide acceptait aussi les requêtes sans Origin/Referer. Pour les organisations qui ont envoyé de telles requêtes au cours des 30 derniers jours, l’option Autoriser les applications mobiles a été activée automatiquement lors de la mise à jour, afin que leurs applications continuent de fonctionner. Pour toutes les autres, l’envoi côté serveur avec la clé publique échoue désormais avec 403 origin_not_allowed – utilisez une clé privée sur les serveurs.

Les requêtes qui portent un Origin ou un Referer sont toujours comparées à la liste : activer l’option n’affaiblit donc pas la protection de vos sites web. Origin: null (iframes en sandbox, pages file://) n’est pas considéré comme une application mobile. Turnstile reste obligatoire pour chaque modèle où il est activé. La modification est enregistrée dans le journal d’audit sous security.updated.

Attention

Lorsque les applications mobiles sont autorisées, les requêtes sans en-tête Origin sont acceptées de n’importe où – tout script ou serveur qui connaît votre clé publique peut les envoyer. Appuyez-vous sur les rate limits, sur Turnstile et sur la liste de blocage, et ne placez jamais de clé privée dans une application. Voir React Native.

Ce que cela protège (et ce que cela ne protège pas)

Les navigateurs définissent eux-mêmes l’en-tête Origin et les scripts ne peuvent pas le falsifier : la liste empêche donc d’autres sites d’intégrer votre clé. En revanche, un script exécuté hors d’un navigateur (curl, un bot) peut envoyer n’importe quel en-tête Origin. C’est pourquoi les domaines autorisés ne sont qu’une couche de protection, combinée à Turnstile, aux rate limits et à la protection contre les bots.

Les requêtes avec une clé privée ne passent pas par la vérification de l’origine – elles viennent de serveurs, qui n’ont pas d’origine. Une requête avec clé privée qui porte un en-tête Origin vient d’une page web, où chaque visiteur peut lire la clé ; elle est refusée avec 403 private_key_in_browser, sauf si vous activez Autoriser les clés privées dans les navigateurs (voir Clés).

Dépannage

• Fonctionne en local, échoue en production : ajoutez le domaine de production (et la variante www.).
• Échoue dans une application native ou depuis un script serveur (403 origin_not_allowed, details.reason: "no_origin") : activez Autoriser les applications mobiles pour les applications ; sur les serveurs, utilisez une clé privée.
• Échoue dans une WebView mobile ou une extension de navigateur : l’origine peut être null, file:// ou chrome-extension://…. Envoyez plutôt depuis votre backend avec une clé privée.
• Échoue derrière une extension de confidentialité qui supprime Referer : les navigateurs modernes envoient toujours Origin sur les requêtes POST, c’est donc rare ; examinez la requête dans les DevTools.

Dans le tableau de bord

Consultez Paramètres de sécurité pour une visite guidée de la page Sécurité.