Antispam para formularios: CAPTCHA y bloqueo de bots - Módulo PrestaShop

El spam no se detiene en el formulario

Un CAPTCHA clásico protege la visualización del formulario, no su tratamiento. Un robot que envía directamente una petición POST al controlador de contacto, registro o boletín se salta el widget y deja su mensaje. Por eso hay tiendas que siguen recibiendo spam con reCAPTCHA activo. Los módulos gratuitos suelen limitarse a un proveedor y a unos pocos formularios, sin límite de envíos, sin registro y sin forma de comprobar qué ocurre.

Antispam para formularios: CAPTCHA y bloqueo de bots coloca una comprobación en el servidor delante de cada formulario protegido. El envío se examina al principio de la petición, antes de que PrestaShop o el módulo del formulario lo trate: un envío rechazado no crea ninguna cuenta, no envía ningún mensaje, no suscribe a nadie al boletín y no publica ninguna opinión. El módulo funciona sin cuenta de terceros ni clave por defecto; un CAPTCHA externo sigue siendo una elección, formulario por formulario.

Una protección en el envío, antes del tratamiento

Cada formulario protegido recibe un token firmado, un campo trampa invisible y un tiempo mínimo de cumplimentación. El servidor comprueba la firma del token, la antigüedad de la página, el campo trampa y los duplicados antes de aceptar el envío. Un robot que envía sin cargar la página no tiene token válido; un robot que rellena todo el formulario también rellena el campo trampa.

• Token firmado: vinculado al formulario, a la tienda y a la hora; caduca a las 12 horas por defecto y se renueva en la primera interacción con un formulario antiguo.
• Campo trampa: oculto fuera de la pantalla, nunca accesible con el teclado, con un nombre elegido al azar en la instalación.
• Tiempo mínimo: de 0 a 30 segundos según el formulario, de 1 a 3 segundos por defecto en los formularios sensibles, para detener los envíos instantáneos.
• Duplicados: un contenido idéntico reenviado dentro de la ventana configurada se rechaza, mientras que una corrección después del rechazo pasa.

Una red de seguridad protege a los visitantes reales: mientras un formulario nunca haya enviado los campos del módulo (un tema o un módulo que dibuja el formulario a su manera), la falta de token se registra sin bloquear, y el panel propone probar la protección. En cuanto se ha visto un envío válido, la falta de token se rechaza.

Los métodos sin cuenta de terceros están activados por defecto

En la instalación, los siete formularios nativos pasan a modo protegido, sin CAPTCHA externo: contacto, creación de cuenta, inicio de sesión, formulario del cliente del pedido, contraseña olvidada, boletín y opiniones de productos. La tienda queda protegida sin clave, sin suscripción y sin llamada a un servicio externo. No se carga ningún script de proveedor mientras no elija uno.

El CAPTCHA que elija, formulario por formulario

Cuando quiera una verificación adicional, elija un proveedor para un formulario concreto: Google reCAPTCHA v2 (casilla o invisible), reCAPTCHA v3 con umbral de puntuación, Cloudflare Turnstile, hCaptcha (normal, compacto o invisible) o Friendly Captcha. Usted introduce sus propias claves, el módulo nunca las vuelve a mostrar y un botón de prueba comprueba que se aceptan. Por defecto, el script del proveedor solo se carga en las páginas que contienen un formulario protegido por ese proveedor, en la primera interacción con el formulario.

• Si el proveedor no responde: dejar pasar (el envío pasa y se registra como sin comprobación) o rechazar, según su elección.
• Consentimiento: el script puede esperar el acuerdo del visitante, con el módulo Cookies RGPD u otra herramienta de consentimiento; sin acuerdo, el formulario sigue protegido por las comprobaciones nativas, o muestra un mensaje si elige pedir el consentimiento.
• Accesibilidad: las variantes invisibles evitan una casilla adicional; un CAPTCHA visible puede molestar a algunos visitantes, la elección es suya.

Límites de envío, listas y bloqueos temporales

Cada envío cuenta en una ventana deslizante por dirección IP y por dirección de correo, con umbrales configurables por formulario. Al superarlos, el envío se rechaza; tras varios avisos, la dirección se bloquea temporalmente en todos los formularios protegidos. La navegación sigue siendo posible: el módulo nunca bloquea una página.

• Listas de bloqueo y de permitidos: direcciones IPv4 e IPv6, rangos CIDR, direcciones de correo, dominios y patrones con comodín; alta manual, importación y exportación CSV.
• Dominios desechables: una lista incluida en la instalación que puede ampliar o recortar, y una comprobación MX opcional con caché.
• Una dirección presente en las dos listas se permite: gana la lista de permitidos.

Observar antes de bloquear y entender después

El modo observación ejecuta todas las comprobaciones y registra lo que se habría bloqueado, sin rechazar nada. Durante unos días compruebe que sus clientes pasan y después active la protección formulario por formulario. El panel muestra los envíos permitidos, bloqueados, observados, sin comprobación y exentos, la tasa de bloqueo, una gráfica de 30 días, el detalle por formulario y por motivo, y las direcciones más bloqueadas.

El registro de intentos bloqueados indica, para cada rechazo, el formulario, el motivo, la fecha, la dirección enmascarada o con hash y el dominio de correo. Puede bloquear una dirección o un rango, permitir una dirección, bloquear un dominio o levantar un bloqueo con un clic, y exportar el registro a CSV. La purga es automática a los 30 días por defecto.

La herramienta Probar mi protección lee la página del formulario como un visitante, comprueba que los campos, el token y el script están presentes, envía un envío directo sin campos para verificar que se rechaza y comprueba las claves del proveedor elegido. El resultado queda visible hasta la siguiente prueba.

Los formularios cubiertos

El módulo protege los siete formularios nativos de PrestaShop, incluida la creación de cuenta durante el pedido. Para los formularios de otros módulos hay dos soluciones: una regla por controlador, con el campo que marca el envío y el formato de respuesta esperado, o la API PHP documentada para que un módulo llame a las comprobaciones desde su propio código. Una regla lista para usar cubre las alertas de disponibilidad de ps_emailalerts.

El pedido en sí nunca se filtra: ni la cesta, ni el pago, ni la confirmación, ni las direcciones. Los umbrales del formulario del cliente del pedido son deliberadamente amplios y sin tiempo mínimo, para no perder nunca una venta.

Verificación del correo en el registro, opcional

Desactivada por defecto, añade un enlace firmado y caducable al registro en la página de creación de cuenta. Una cuenta pendiente no puede iniciar sesión antes de la confirmación y puede pedir un nuevo enlace. La tienda nunca retiene una cuenta si no envía correos o si el envío falla, y una cuenta pendiente sigue siendo accesible si el módulo se desactiva o la licencia caduca.

Exenciones y privacidad

Los empleados conectados al panel, los rastreadores de motores de búsqueda verificados, los grupos de clientes que exima, las direcciones permitidas, los clientes conectados (según el formulario) y las tareas programadas no se comprueban. Por defecto el registro nunca contiene una dirección en claro: la dirección se enmascara, una huella con hash sirve para las listas y los límites, y se conserva el dominio del correo sin la dirección completa. Usted elige el plazo de conservación y puede exportar o borrar los datos mediante los hooks RGPD.

El módulo ayuda a reducir el spam y a limitar los datos recogidos; no certifica el cumplimiento del RGPD ni sustituye un asesoramiento jurídico. Los CAPTCHA externos tienen sus propias condiciones y política de privacidad: debe mencionarlos en su política y elegir el consentimiento adecuado.

Multitienda, idiomas y licencia

Los ajustes, formularios, registro y estadísticas son propios de cada tienda; las entradas de las listas pueden ser de una tienda o compartidas. La interfaz y los mensajes existen en francés, inglés, español, italiano y polaco; los temas Classic y Hummingbird funcionan sin modificación. La desinstalación conserva los datos por defecto, con una opción para eliminarlos.

El módulo funciona con una licencia WePresta válida. Sin licencia válida se desactiva: los formularios dejan de comprobarse, no se muestra ningún CAPTCHA y no se registra nada, así que el spam puede volver. Sus ajustes, listas y registro se conservan, y el módulo se reactiva en cuanto la licencia es válida.

Requisitos y límites

• PrestaShop 1.7.8, 8.0+ o 9.0+; PHP 7.4 o superior.
• No se exige ninguna cuenta de pago. Los proveedores de CAPTCHA son opcionales y requieren sus propias claves; Cloudflare Turnstile requiere una cuenta de Cloudflare.
• Una tarea programada (dirección con token o línea de comandos) ejecuta el mantenimiento diario: purga del registro, de los contadores y de los bloqueos caducados.
• Las verificaciones de CAPTCHA y la comprobación MX usan llamadas de red salientes; sin red se aplica el comportamiento que haya elegido.
• Ningún módulo puede prometer cero spam. Este módulo reduce con fuerza los envíos automatizados y le da medios para ver y ajustar; no sustituye su política de privacidad ni un asesoramiento jurídico.
• Un límite demasiado estricto puede molestar a visitantes detrás de una misma dirección (empresa, operador móvil): use el modo observación y las listas de permitidos antes de activar.