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

Formularios enviados con AJAX

El widget notifica un envío cuando el formulario se envía con un submit normal. También notifica las solicitudes realizadas con XMLHttpRequest, incluido jQuery.ajax, siempre que el cuerpo de la solicitud contenga el campo behavior_nonce: retiene la solicitud un momento, notifica los datos de escritura y de ratón y envía la solicitud en cuanto llega el veredicto, como máximo a los 15 segundos. Por eso, serialice el formulario completo, con los campos ocultos. Su comprobación en el servidor no cambia.

No cubiertas: las solicitudes realizadas con fetch() y las solicitudes síncronas. Para ellas el servidor no recibe datos de escritura ni de ratón y /v1/verify responde suspicious.

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.