Cómo evitar que los bots se registren en su sitio

Aplique controles en el servidor

Mantenga las comprobaciones de formato en el formulario para dar una respuesta inmediata y vuelva a validar en el servidor. Un campo de correo del navegador comprueba la forma de la dirección; no establece que exista el buzón ni detiene peticiones HTTP directas. MDN explica por qué hacen falta ambas validaciones.

Limite la frecuencia de las peticiones de registro y de los mensajes de confirmación. Elija los límites según su tráfico y el coste de crear una cuenta; muchos visitantes legítimos pueden compartir una IP. Un honeypot es un campo adicional que no se espera que rellenen las personas y que puede detectar envíos automatizados sencillos. Compruébelo en el servidor y verifique que el autocompletado y las herramientas de asistencia no causen rechazos incorrectos. Los scripts más preparados pueden dejarlo vacío.

Reserve las funciones de prueba costosas y otras ventajas hasta que se cumplan sus requisitos. Examine las ráfagas de cuentas nuevas junto con lo que hacen después. Estos controles siguen el enfoque por capas de la guía contra la automatización de OWASP. Los límites de frecuencia, honeypots y restricciones de prueba los implementa usted; Signup Protection no los proporciona ni configura.

Obtenga un token al mostrar el formulario

Emvero Signup Protection compara la conexión que obtiene un token de página con la petición que envía el formulario. Añade evidencia de esa visita a la decisión del correo. No devuelve un booleano humano/bot ni un identificador persistente de visitante, y no cuenta cuentas repetidas entre visitas.

Abra Signup Protection en su cuenta, active la conexión y espere a que esté lista. Añada una clave de página para los orígenes HTTPS del formulario. La clave de página fp_key_… es pública y va en el navegador; la clave secreta de API emv_… se queda en el servidor.

Cargue fp-token.js y el archivo independiente fp-probe.js con el código de cliente de su cuenta. Mantenga dentro del formulario un campo oculto, como fp_token. Cuando sea visible, cree FpToken con el endpoint, la clave de página y las opciones, y llame a visitToken.fetch(vid). Si el formulario ya se ve al cargar, inicialice cuando la página esté lista; si está en un diálogo, espere a abrirlo. Respete el consentimiento que corresponda. La opción { quic: true } activa una sesión opcional de WebTransport.

vid es un identificador opaco de la visita, enviado como cadena o promesa. No use un ID de cuenta, una dirección de correo ni un teléfono. fetch(vid) se resuelve con el token o una cadena vacía. Su código escribe el resultado en el campo oculto; la biblioteca no lo actualiza. Si el archivo de prueba falta o es incompatible, no habrá token. Una comprobación individual del navegador puede quedar sin evaluar aunque el token sea utilizable.

Empiece a recoger los datos mientras la persona ve y rellena el formulario. Hacerlo solo al enviarlo puede provocar el hallazgo de envío rápido. En formularios largos, vuelva a llamar a visitToken.fetch() antes de que caduque y actualice el campo. La prueba conserva un token anterior utilizable en la memoria de la página. Con un token anterior utilizable, la hora de la primera emisión solo se conserva si no cambian la dirección IPv4 o el prefijo IPv6 /64, la familia, versión principal y plataforma del navegador, y la visita no supera las 24 horas. En los demás casos, el tiempo empieza a contarse de nuevo. Enviar el formulario poco después puede provocar el hallazgo de envío rápido. El perfil actual tiene una validez de 15 minutos. Envíe con el formulario el valor opaco actual del campo.

Si falla el script o la petición del token, el campo puede quedar vacío y el formulario puede enviarse. Gestione el resultado en el servidor. Las instrucciones de instalación incluyen el script, los orígenes permitidos, la renovación y Content-Security-Policy. El archivo de prueba se actualiza por separado del script del token. Si se bloquea o no está disponible, no se obtiene un token. Con un token utilizable, alguna comprobación individual del navegador puede seguir sin evaluarse.

Elija la comprobación del servidor

Use POST /v1/signup-checks para comprobar juntos el correo y la visita. Envíe email, el campo oculto como token y la ip, el user_agent y los client_hints disponibles que observe el servidor. Si hay un proxy, obtenga la IP mediante la configuración de proxies de confianza; no se fíe de un campo del formulario que afirme contenerla.

Si ya comprueba el correo en otro sistema o lo hará más adelante, use POST /v1/signup-signals sin email ni variant. La acción se basa solo en las señales y no sustituye a la regla de correo aplicada en otro paso. La falta de datos limita las comparaciones posibles; no demuestra que hayan resultado favorables.

Las señales evaluadas cuestan cinco créditos. Los resultados de señales token_unusable y unavailable no consumen créditos por señales; una comprobación combinada cobra el correo por separado. Debe haber saldo suficiente para las reservas antes de continuar. Consulte los precios y el calculador de créditos y el contrato de petición y respuesta.

Vincule la acción con el acceso a la cuenta

Aplique la action externa de la respuesta combinada según la tabla anterior. Mantenga separados email.status, signals.status y action en su código. Las señales pueden exigir confirmar el correo, pero no causar reject; nunca suavizan la decisión del correo.

Para allow_with_email_confirmation, su aplicación envía un mensaje y comprueba su enlace o código antes de conceder el acceso correspondiente. La verificación de Emvero no envía mensajes a la dirección comprobada. Confirmar demuestra el control del buzón, no que la cuenta pertenezca a una persona única. La guía de validación del formulario de registro explica los resultados de correo; verificación y confirmación distingue ambos procesos.

Los hallazgos de la prueba fp_probe_forged y fp_probe_automation exigen confirmación cuando el correo permitiría continuar. fp_probe_tampering es informativo. La matriz independiente signals.notes incluye bot_claim y bot_operator, además de observaciones de conexión y navegador. Estas notas distinguen rastreadores y herramientas declarados sin cambiar la acción por defecto. Incluso una declaración de rastreador fuera de la red de su operador es informativa. La ausencia de esa declaración no demuestra que el visitante sea humano.

Use signal_codes para ver qué hallazgos elevaron la acción y signals.findings para ver la evidencia más completa. Los reason_codes del correo permanecen en email. Los hallazgos de VPN, Tor, proxy y alojamiento son informativos por defecto y no elevan la acción por sí solos.

Distinga comprobaciones incompletas y errores

Un token vacío produce signals.status: token_unusable con fp_token_absent y exige confirmación si el correo permitiría continuar. Una caída del servicio produce signals.status: unavailable; la acción combinada sigue solo el correo. Decida qué acceso permite su aplicación durante esa caída. Las señales no disponibles no demuestran que la visita sea segura.

Cuando email.status es pending, mantenga la confirmación y consulte GET /v1/signup-checks/{id} tras email.retry_after_ms. La consulta devuelve las señales guardadas con el resultado actual del correo y recalcula la acción. No vuelve a evaluar la visita. Un resultado de correo unknown expresa incertidumbre, no que la dirección sea inválida.

Un error HTTP es otro resultado de integración. Corrija los campos tras 400, compruebe el saldo tras 402 y gestione una conexión desactivada tras 409 signup_protection_disabled. Respete Retry-After en límites reintentables o peticiones en curso. Un fallo contable no es un resultado del registro: conserve el intento y siga las instrucciones de errores y reintentos de la API. Una petición combinada puede empezar a evaluar señales antes de que falle la reserva del correo; 402 no garantiza que no se haya ejecutado una petición de señales.

Reintente con la misma clave de operación

Cree un Idempotency-Key por intento lógico de registro y guarde la clave y el contenido para reintentos de transporte. Dentro del plazo de 30 minutos, la misma clave y el mismo contenido devuelven la comprobación guardada sin otra evaluación de señales ni otro cobro. En una comprobación combinada, ese registro puede incluir un resultado de correo más reciente. Usar la misma clave con otro contenido produce 409 idempotency_conflict. Si la primera petición sigue en curso, 409 request_in_progress indica que debe esperar según Retry-After.

Una operación nueva con el mismo token es distinta de un reintento idempotente: puede producir fp_token_reused y exigir confirmación. El registro de reutilización se comparte entre ambas rutas de comprobación dentro de la cuenta. Use un token nuevo para un intento nuevo y la clave original para reintentar un envío. Consulte las instrucciones de idempotencia.

Pruebe registros habituales e incompletos

• Complete un formulario habitual después de empezar la recogida. Compruebe que el servidor recibe el token y los datos observados, y aplica la acción externa. Una visita corriente tampoco garantiza allow.
• Envíe el formulario sin token. Compruebe que su aplicación recibe token_unusable y ofrece la confirmación necesaria del buzón.
• Simule señales unavailable y correo pending en su entorno de pruebas. Compruebe por separado la regla para caídas y las consultas a las comprobaciones guardadas.
• Reintente la misma petición con la clave guardada. Después, pruebe una operación nueva con el mismo token. Verifique la diferencia entre un reintento y fp_token_reused.
• Pruebe un correo rechazado y un hallazgo informativo de red. Debe mantenerse el rechazo del correo; una etiqueta de red por sí sola no debe convertirse en un rechazo de Emvero.

Observe decisiones, comprobaciones incompletas, confirmaciones terminadas y acceso a las ventajas de prueba. No incluya tokens ni claves secretas en los logs. Ajuste los límites según los abusos observados y los registros legítimos que fallen. Emvero no ofrece un editor de reglas propias de registro ni un conector de CMS listo para usar.