Vérification côté serveur

Vérifiez toujours le nonce SilentShield sur votre serveur. Les vérifications côté client seules peuvent être contournées par les bots.

Pourquoi côté serveur ?

Le Widget s'exécute dans le navigateur et injecte un nonce dans les formulaires. Un bot pourrait ignorer le Widget et soumettre le formulaire directement. La vérification côté serveur garantit que le nonce a été légitimement émis et vérifié par SilentShield.

Point d'accès API

Method: POST
URL: https://api.silentshield.io/api/v1/captcha/verify-nonce
Headers: X-Api-Key: YOUR_API_KEY Content-Type: application/json
Body: { "nonce": "the-nonce-from-the-form" }

Format de la réponse

Responsejson

{
  "ok": true,
  "verdict": "human",
  "confidence": 0.92,
  "requested_nonce": "..."
}

human: human — L'utilisateur est très probablement humain. Traitez le formulaire.
suspicious: suspicious — le serveur a refusé (HTTP 403, `ok: false`). Le verdict indique le motif, pas la décision : celle-ci a déjà été prise par le seuil de votre compte.
bot: bot — Forte probabilité qu'il s'agisse d'un bot. Rejetez le formulaire.

Logique recommandée

Le serveur a déjà appliqué le seuil de votre compte : un refus arrive en HTTP 403 avec `ok: false`. Vérifiez donc le passage, et non `bot` — sinon vous laissez passer tout refus prononcé comme `suspicious`, ainsi que toute réponse sans verdict (clé invalide, quota épuisé).

Server-Side Logicjavascript

if not ok or verdict != "human":
    refuser le formulaire (403)
else:
    traiter le formulaire normalement

Formulaires envoyés en AJAX

Le widget signale un envoi lorsque le formulaire est envoyé avec un submit classique. Il signale aussi les requêtes effectuées avec XMLHttpRequest, y compris jQuery.ajax, tant que le corps de la requête contient le champ behavior_nonce : il retient la requête un instant, signale les données de frappe et de souris, puis envoie la requête une fois le verdict reçu, au plus tard après 15 secondes. Sérialisez donc tout le formulaire, champs masqués compris. Votre vérification côté serveur ne change pas.

Non couvert : les requêtes effectuées avec fetch() et les requêtes synchrones. Pour celles-ci, le serveur ne reçoit aucune donnée de frappe ni de souris et /v1/verify répond suspicious.

Gestion des erreurs

Si l'API SilentShield est injoignable (timeout, erreur 5xx), définissez votre stratégie :

Fail Open: Accepter (fail open) — Accepter le formulaire (meilleure expérience utilisateur, moins sécurisé)
Fail Closed: Rejeter (fail closed) — Rejeter le formulaire (plus sécurisé, moins bonne expérience utilisateur)

Pour la plupart des applications, nous recommandons d'accepter avec journalisation. Les formulaires critiques (connexion, paiement) devraient rejeter.