BlogFormularios web
Formularios web: filtrar spam sin perder consultas de clientes
Bloquear bots y recibir consultas útiles son dos resultados. Comprueba ambos, también cuando el cliente pierde conexión.
Hoja de prueba: Formularios web: controlar spam y conservar consultas
Bloquear bots y recibir consultas útiles son dos resultados. Comprueba ambos, también cuando el cliente pierde conexión. Registra datos, resultado esperado, evidencia, responsable y resultado observado.
Define cuándo la consulta se considera recibida
Una empresa de transporte puede pedir origen, destino y fecha; una fábrica recibe solicitudes de cotización con descripción y contacto. Pide solo lo necesario para atender la primera consulta. Define si la recepción ocurre al guardar el registro o al enviarlo a una bandeja. El mensaje de éxito debe corresponder a esa frontera, no aparecer apenas se toca el botón.
Cloudflare Turnstile exige verificar el token en el servidor: el widget por sí solo no protege el formulario. reCAPTCHA también documenta verificación en el backend y tokens de uso único con caducidad. Son controles del proveedor, distintos de guardar la consulta y de entregar su aviso. Prueba cada paso en tu implementación.
Ejemplo ficticio: consulta L-017 sin respuesta visible
Un cliente de ensayo llamado Ana O'Neill escribe con acentos, deja un correo válido y pide una cotización. El servidor guarda L-017, pero la conexión se corta antes de mostrar confirmación. Al volver, la página ofrece consultar o retomar el envío sin crear otro registro. Es un caso sintético, no una medición de contactos o una capacidad declarada del sitio de Nightly.
La prueba también permite un token de verificación vencido. El formulario explica cómo renovar la verificación y conserva los campos ya escritos. No confunde ese resultado con «correo inválido» ni borra la consulta del cliente. Para mensajes que podrían llegar a revisión, usa un estado comprensible en lugar de prometer que un representante ya respondió.
| Capa | Qué comprueba | Qué no demuestra |
|---|---|---|
| Validación de campos | Formato, tamaño y reglas necesarias | Que toda persona sea un cliente real |
| Control de abuso | Resultado de verificación y regla de frecuencia | Que la consulta se haya guardado |
| Recepción | Registro durable o destino acordado | Entrega del correo de aviso |
| Seguimiento | Responsable encuentra y atiende la consulta | Venta o cita confirmadas |
Prueba a la persona que sí quieres atender
OWASP recomienda reglas por campo y advierte que bloquear caracteres como apóstrofes puede rechazar nombres legítimos. Permite texto necesario, limita longitud y valida datos estructurados según su significado. No trates «contiene un enlace» como prueba suficiente de spam: una consulta válida puede incluir una referencia de producto.
| Caso | Resultado esperado | Evidencia |
|---|---|---|
| Ana O'Neill usa nombre y texto con acentos | Consulta válida aceptada sin alterar su significado | Campos y registro L-017 |
| Token de verificación vencido | Renovación clara con campos conservados | Estado y nuevo intento |
| Solicitud llega sin validación del servidor | Rechazo según el control, sin consulta falsa | Resultado del servidor |
| Respuesta se pierde después de guardar | Recuperar confirmación o estado sin duplicar L-017 | Referencia e intentos |
| Correo de aviso falla | Consulta sigue consultable y aviso queda pendiente | Registro y estado de notificación |
| Petición excede límite de campo | Explicación específica sin borrar otros datos | Campo y mensaje de error |
Distingue rechazo, pendiente y recepción confirmada
Acuerda qué ocurre si el servicio de verificación no responde: no declares envío exitoso sin conocer el resultado. Mantén el texto en pantalla y ofrece un canal alternativo apropiado cuando corresponda. Prueba teclado, lector de pantalla, móvil y conexión lenta; un control de spam que impide consultar al cliente legítimo también necesita corregirse.
El identificador para repetir una consulta pertenece a tu operación, no es el mismo que el token de CAPTCHA. Un token puede caducar o ser de un solo uso mientras la consulta necesita recuperar una confirmación. Revisa esa separación y la duración de las referencias. Los controles y límites dependen del proveedor, del patrón de abuso y del riesgo; no prometen eliminar todo spam.
Mide si el equipo puede atender lo recibido
Haz que alguien encuentre L-017 y compruebe su estado sin revisar registros técnicos extensos. Relaciona el ensayo con medir contactos útiles, facilitar la compra y rendimiento web. Una página rápida todavía puede perder consultas si informa un éxito falso.
La hoja contiene diez pruebas con resultados vacíos. Trae los campos del formulario, ejemplos anonimizados de spam y una consulta válida a una consulta gratuita de páginas web. Podemos revisar en qué capa se pierde trabajo y qué ensayo conviene hacer antes de añadir más obstáculos al envío.
Preguntas frecuentes
La elección depende del riesgo y de los controles existentes. Primero identifica abuso y prueba la experiencia de clientes legítimos. Si usas un proveedor de verificación, implementa y comprueba su validación del servidor; el widget visible no es suficiente.
Define reglas necesarias por campo, no una lista genérica de caracteres sospechosos. Apóstrofes, acentos y referencias pueden ser legítimos. La validación no sustituye otras defensas al almacenar o mostrar datos; prueba que no se cambie el significado.
Puede haberse contado un clic, un intento o una consulta cuyo aviso falló. Compara el evento con el registro recibido y el estado de entrega. Un evento analítico no demuestra que el equipo tenga una consulta para atender.
Usa datos ficticios y un destino autorizado de ensayo. Simula la pérdida de respuesta después de guardar y comprueba una sola referencia. No uses una campaña ni direcciones de clientes para verificar ese comportamiento.
Fuentes
- Validate the tokenCloudflare
- Verifying the user's responseGoogle
- Input Validation Cheat SheetOWASP
Última actualización:
