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

Responsejson
{
  "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).

Server-Side Logicjavascript
if not ok or verdict != "human":
    rechazar el formulario (403)
else:
    procesar el formulario con normalidad

Manejo 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.