Verificación del Lado del Servidor
Siempre verifique el Nonce de SilentShield en su servidor. Las verificaciones solo del lado del cliente pueden ser evadidas por bots.
¿Por Qué del Lado del Servidor?
El Widget se ejecuta en el navegador e inyecta un Nonce en los formularios. Un bot podría omitir el Widget y enviar el formulario directamente. La verificación del lado del servidor asegura que el Nonce fue emitido y verificado legítimamente por SilentShield.
Endpoint de la 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" }
Formato de Respuesta
{
"ok": true,
"verdict": "human",
"confidence": 0.92,
"requested_nonce": "..."
}human- human — Es muy probable que el usuario sea humano. Procese el formulario.
suspicious- suspicious — el servidor lo rechazó (HTTP 403, `ok: false`). El veredicto indica el motivo, no la decisión: esa ya la tomó el umbral de su cuenta.
bot- bot — Alta confianza de que es un bot. Rechace el formulario.
Lógica Recomendada
El servidor ya ha aplicado el umbral de su cuenta: un rechazo llega como HTTP 403 con `ok: false`. Compruebe por tanto si hay paso, no si hay `bot`: de lo contrario deja pasar todo rechazo emitido como `suspicious` y toda respuesta sin veredicto (clave no válida, cuota agotada).
if not ok or verdict != "human":
rechazar el formulario (403)
else:
procesar el formulario con normalidadManejo de Errores
Si la API de SilentShield no es accesible (tiempo de espera agotado, error 5xx), decida su estrategia:
- Fail Open
- Fail open — Aceptar el formulario (mejor experiencia de usuario, menos seguro)
- Fail Closed
- Fail closed — Rechazar el formulario (más seguro, peor experiencia de usuario)
Para la mayoría de las aplicaciones, recomendamos fail open con registro de eventos. Los formularios críticos (inicio de sesión, pagos) deben usar fail closed.