Vérifier sans backend
Un token Caputchin ne prouve rien tant que quelque chose ne le confirme pas. Normalement, ce quelque chose est ton propre backend, qui appelle /siteverify et décide s'il faut faire confiance à la requête. La vérification hébergée déplace cette étape vers Caputchin : ton formulaire poste vers un relais Caputchin, Caputchin vérifie le token, laisse tomber tout ce qui échoue, et ne relaie que les envois vérifiés vers une destination que tu choisis.
C'est la même décision de confiance que la vérification backend, exécutée du côté de Caputchin plutôt que du tien. L'intérêt, c'est qu'il n'y a pas d'appel /siteverify à écrire ni de secret à garder sur un serveur, parce qu'il n'y a pas de serveur.
La vérification hébergée est une fonctionnalité payante, disponible sur Alpha et au-dessus.
À qui elle s'adresse
La vérification hébergée existe pour le cas où exécuter un backend juste pour vérifier un token est plus que ce dont le projet a besoin.
| Tu es | Pourquoi ça convient |
|---|---|
| Un site statique (Webflow, Framer, HTML pur sur un CDN) | Il n'y a pas de serveur pour recevoir le formulaire ou appeler /siteverify. |
| Un constructeur no-code (Wix, Squarespace, Carrd) | Tu ne peux pas ajouter de code de vérification côté serveur. |
| Un développeur solo ou une petite équipe | Un formulaire de contact ou d'inscription ne vaut pas la peine de monter et d'exploiter un backend. |
| Déjà sur un backend, mais pas pour ce formulaire | Tu peux pointer un formulaire vers le relais et laisser le reste de ta stack tranquille. |
Si tu exécutes bien un backend et veux vérifier là, utilise plutôt vérifier sur ton backend. Les deux sont des alternatives, pas des couches.
Comment ça marche
Le relais retient l'envoi en mémoire seulement le temps qu'il faut pour le livrer. Il n'y a aucun stockage entre le post et la livraison, et le champ caputchin-token est retiré avant que la charge n'atteigne ta destination.
Destinations
Tu en configures une ou les deux par clé de site. Activer les deux est un schéma courant : envoie vers un webhook pour le traitement et envoie-toi une copie par e-mail.
| Destination | Ce que tu reçois |
|---|---|
| Webhook | Un POST JSON portant les champs de ton formulaire plus les métadonnées de vérification de Caputchin. |
| Un e-mail simple avec les champs du formulaire et un pied de page notant que Caputchin a vérifié l'envoi. |
Les livraisons ne sont pas signées. C'est le secret de l'URL du relais qui authentifie un appel de webhook, donc garde l'URL hors des dépôts publics et du code côté client. Le tutoriel de configuration montre la charge exacte du webhook.
Ce qui reste privé
La vérification hébergée suit la même posture sans-donnée-visiteur que le reste de Caputchin :
- Les envois ne sont jamais stockés. Ils vivent en mémoire de processus le temps du relais, puis ils ont disparu. Construis ton propre relevé côté webhook si tu en veux un.
- Aucune donnée sur l'envoyeur n'est collectée. Pas d'IP, pas de User-Agent, pas d'empreinte, pas de pistage.
- La télémétrie est seulement agrégée. Caputchin compte les réussites et échecs de livraison pour que tu voies si tes destinations sont en bonne santé, jamais le contenu d'un envoi. Vois statistiques.
Comment une URL fournie par le client reste sûre
Une URL que les serveurs de Caputchin appelleront est un risque classique de Server-Side Request Forgery. Le relais rejette toute URL de webhook dont l'hôte est une adresse privée, de bouclage, link-local ou de métadonnées cloud, à la fois quand tu l'enregistres et de nouveau juste avant chaque livraison. Les catégories bloquées incluent :
| Catégorie | Exemples |
|---|---|
| Bouclage et non spécifiée | 127.0.0.1, 0.0.0.0, ::1 |
| Privée (RFC 1918) | 10.x.x.x, 172.16.x.x à 172.31.x.x, 192.168.x.x |
| Link-local et métadonnées cloud | 169.254.x.x, en particulier le point de terminaison de métadonnées 169.254.169.254 |
| NAT de classe opérateur | 100.64.x.x à 100.127.x.x |
| Multicast et réservées | 224.x.x.x et au-dessus |
| Noms d'hôte internes | localhost et tout hôte se terminant par .local, .localhost ou .internal |
| IPv6 privée | adresses link-local (fe80::/10) et unique-local (fc00::/7) |
Les encodages qui tentent de déguiser une adresse bloquée sont attrapés aussi : un hôte en entier décimal comme http://2130706433/ ou un hôte hexadécimal comme http://0x7f000001/ (qui signifient tous deux 127.0.0.1) sont rejetés. Seules les URL http et https sont acceptées ; tout autre schéma est refusé. Le relais refuse aussi de suivre les redirections, donc un point de terminaison de webhook ne peut pas renvoyer l'appel vers une cible interne. Une URL bloquée remonte comme une erreur générique plutôt que spécifique, donc elle ne peut pas servir à sonder un réseau. Ton webhook doit donc vivre à une URL https publique.
Ce qui est laissé de côté intentionnellement
- Pas de boîte de réception d'envois. Il n'y a aucun historique stocké des envois à parcourir dans le tableau de bord.
- Pas d'adaptateurs Discord, Slack, Telegram ou SMS propriétaires. Webhook et e-mail seulement. Un webhook peut diffuser vers n'importe lequel de ton côté.
- Pas de téléversement de fichiers. Le relais accepte les champs texte ; un envoi portant un fichier est rejeté.
- Pas de transformation de charge. Ce que le formulaire poste est ce que ta destination reçoit, plus les métadonnées de vérification.
Voir aussi
- Configurer la vérification hébergée : une marche à suivre qui la câble d'abord à une boîte de test.
- Statistiques de vérification hébergée : lire la santé de livraison.
- Vérifier sur ton backend : l'alternative quand tu exécutes bien un serveur.