Sécurité
La page Sécurité d'une clé de site décide de la difficulté de l'épreuve et des requêtes autorisées à l'atteindre. Les valeurs par défaut sont un milieu raisonnable ; cette page explique quand s'en écarter, et dans quel sens.
Commence ici
La plupart des sites devraient laisser les valeurs par défaut tranquilles. Tends la main vers les molettes ci-dessous quand tu as une raison :
- Tu subis un abus actif, ou le formulaire est à forte valeur (inscriptions, paiements, réinitialisation de mot de passe) : monte la protection. Augmente la Difficulté, augmente le Niveau d'obfuscation, et active Bloquer les navigateurs automatisés. Tu échanges un peu de calcul visiteur et de CPU serveur contre un mur bien plus haut.
- La vitesse et la conversion priment, et le risque est faible (une case newsletter sur une page marketing) : garde la protection légère. Laisse la Difficulté basse et les Défis par requête à 1 pour que l'épreuve soit plume sur un téléphone bon marché.
Le reste de cette page, c'est chaque molette et dans quel sens la tourner.
Exiger un jeu
Le contrôle le plus fort ici est d'exiger qu'un visiteur joue un jeu pour passer, pas seulement réussir le contrôle de fond discret. Active Exiger un jeu pour vérifier, ici sur la page Sécurité, et chaque visiteur doit réussir l'un des jeux enregistrés sur cette clé. Le serveur choisit quel jeu reçoit chaque visiteur, donc il ne peut être ni sauté ni échangé.
Tu enregistres les jeux qu'une clé peut utiliser, et c'est aussi là que le gate s'explique en entier, sur la page Jeux et le gate de jeu de la clé. Tu ne peux pas activer le gate tant qu'au moins un jeu n'est pas enregistré. Le laisser désactivé est le choix le moins sûr : la clé peut être passée sans jouer de jeu.
Proof of work : Difficulté et Défis par requête
Le proof of work fait résoudre au navigateur un petit casse-tête pour que l'abus à grande échelle devienne coûteux (voir proof of work).
- Difficulté (1 à 8) fixe la dureté de chaque casse-tête. Plus haut coûte plus à un attaquant, mais coûte aussi plus à l'appareil du visiteur, ce que les téléphones d'entrée de gamme ressentent en haut de la plage. Commence à la valeur par défaut et ne l'augmente que si tu vois réellement de l'abus.
- Défis par requête (1 à 500) demande plusieurs résolutions à la fois, multipliant le coût. Laisse à 1 sauf si tu as une raison précise d'en empiler davantage.
Le navigateur résout ces casse-têtes dans un Web Worker, donc la Content-Security-Policy de ta page doit autoriser blob: pour les workers (worker-src blob:) ; celle-ci est requise. Autoriser 'wasm-unsafe-eval' dans script-src permet en plus au solveur de tourner en WebAssembly rapide, mais c'est optionnel : sans cela, le solveur retombe sur une implémentation JavaScript pure plus lente dans le même Worker et la vérification fonctionne toujours. Vois bac à sable des jeux pour la politique complète de la page hôte.
Instrumentation : Niveau d'obfuscation et Bloquer les navigateurs automatisés
L'instrumentation exécute un petit programme dans le navigateur du visiteur pour vérifier qu'un vrai navigateur, pas un script, a résolu l'épreuve (voir instrumentation). Elle est active par défaut et c'est la seule couche qui distingue un vrai navigateur d'un navigateur automatisé.
- Instrumentation peut être désactivée par clé. Laisse-la active pour presque chaque site. Ne la désactive que si la page qui intègre ton widget exécute une Content-Security-Policy qui ne peut pas autoriser
'unsafe-eval'(le programme d'instrumentation en a besoin, voir ci-dessous). Avec elle désactivée, la clé ne peut plus détecter les navigateurs automatisés, bien que le proof of work et tout jeu requis tournent encore, et les deux réglages ci-dessous cessent de s'appliquer. - Niveau d'obfuscation (1 à 10) est la difficulté de rétro-ingénierie du programme dans le navigateur. Plus haut est plus fort mais utilise plus de CPU serveur. La valeur par défaut convient à la plupart des sites ; augmente-la si tu es la cible fréquente et ciblée d'un attaquant.
- Bloquer les navigateurs automatisés rejette purement et simplement les clients headless et WebDriver détectés. Active-le si aucune automatisation légitime ne touche jamais ton formulaire. Laisse-le désactivé si tu attends des bots légitimes (ta propre surveillance, des intégrations partenaires, des outils d'accessibilité), parce qu'il les bloquera aussi.
Content-Security-Policy
Le programme d'instrumentation exécute eval dans le navigateur du visiteur, donc la page qui intègre ton widget doit autoriser 'unsafe-eval' dans son script-src. C'est l'unique exigence CSP stricte et elle n'a pas de repli : si 'unsafe-eval' est bloqué, la vérification expire et la console du navigateur affiche [cap] Instrumentation failed. Tu as deux choix : autoriser 'unsafe-eval' sur les pages qui hébergent le widget, ou désactiver l'Instrumentation (ci-dessus) pour retirer l'exigence. La liste complète de ce que la CSP d'une page hôte requiert est sur bac à sable des jeux.
En-têtes requis
Tu peux exiger que chaque requête porte un en-tête précis. La plupart des sites n'en ont pas besoin ; c'est utile quand ton propre client envoie toujours un en-tête sur lequel tu peux gater, comme filtre supplémentaire bon marché.
Ce que tu ne peux pas exiger, ce sont les en-têtes que Caputchin retire pour la confidentialité avant qu'une requête n'atteigne jamais la vérification. Ils identifient le visiteur, et la posture de Caputchin est de ne pas collecter de données par visiteur, donc il les laisse tomber à la frontière de la plateforme :
| En-tête retiré | Pourquoi il est retiré |
|---|---|
cf-connecting-ip | L'IP du visiteur, fixée par Cloudflare. Ne franchit jamais la frontière, donc Caputchin ne la stocke ni ne s'y compare. |
x-forwarded-for | L'IP du visiteur telle que vue à travers les proxys. Même raison. |
x-real-ip | L'IP du visiteur depuis les proxys en amont. Même raison. |
user-agent | La chaîne User-Agent du visiteur, qui identifie son navigateur et son appareil. |
sec-ch-ua* (chaque client hint Sec-CH-UA : sec-ch-ua, sec-ch-ua-platform, sec-ch-ua-mobile, et le reste) | La forme structurée du User-Agent. Même frontière de confidentialité. |
Exiger l'un d'eux bloquerait chaque requête, parce qu'il n'arrive jamais, donc la plateforme rejette cette configuration plutôt que de te laisser briquer la clé.
Limite de débit et origines CORS
- Maximum de requêtes par seconde plafonne la vitesse à laquelle la clé accepte les requêtes. Augmente-le si tu es vraiment à fort trafic ; baisse-le pour brider une clé qui se fait marteler.
- Origines CORS est ta liste d'origines autorisées, appliquée côté serveur avant même que le casse-tête ne tourne. Laisse-la vide tant que tu testes depuis
localhost; avant la mise en ligne, ajoute tes vraies origines pour que seul ton propre site puisse utiliser la clé.
Voir aussi
- Jeux et le gate de jeu pour enregistrer des jeux et en exiger un pour vérifier.
- Clés de site pour le reste d'une clé.
- Statistiques et sessions pour voir si tes réglages arrêtent le bon trafic.