Cómo bloquear el spam de los formularios PrestaShop: CAPTCHA y bots

Su formulario de contacto recibe cada noche mensajes idénticos, en inglés, con un enlace. Las inscripciones crean cuentas con direcciones inverosímiles y la newsletter acumula direcciones que nunca pidieron nada. Sin embargo, hay un CAPTCHA activo. Casi siempre protege solo la visualización del formulario: un bot que envía una petición POST directamente al controlador nunca lo carga. Esta guía explica cómo recuperar el control en el servidor, qué formularios proteger, cómo configurar el módulo sin perder clientes y cómo leer lo que se rechaza.

¿Por qué sigue llegando spam con un CAPTCHA activo?

Porque un CAPTCHA protege la visualización del formulario, no su tratamiento. Un bot que conoce la dirección del controlador envía los campos esperados directamente al servidor, sin navegador y sin widget.

Los controladores de contacto, registro y newsletter son públicos y fáciles de identificar. Basta una petición POST bien formada: el widget nunca se carga y el mensaje llega a la bandeja. Por eso hay tiendas que siguen recibiendo spam con reCAPTCHA activo.

¿Qué formularios protege el módulo?

El módulo Antispam para formularios: CAPTCHA y bloqueo de bots protege los siete formularios nativos de PrestaShop: contacto, creación de cuenta, inicio de sesión, formulario de cliente del pedido, contraseña olvidada, suscripción a la newsletter y opiniones de productos.

En la instalación, esos siete formularios pasan al modo Protegido, sin CAPTCHA externo. La página Formularios los enumera con su modo, su CAPTCHA, su tiempo mínimo, sus límites, la fecha del último envío y el estado Campos en la página. Editar abre los ajustes de un formulario; Proteger todo y Observar todo cambian el modo de toda la lista.

Para los formularios de otros módulos hay dos soluciones. Una regla apunta a un controlador, con el campo que marca el envío y el formato de respuesta esperado; Añadir una regla la crea, hasta 20 reglas por tienda. Una regla preparada cubre las Alertas de disponibilidad de productos (ps_emailalerts). La API PHP documentada permite que un módulo llame a las comprobaciones desde su propio código.

El pedido en sí nunca se filtra: ni el carrito, ni el pago, ni la confirmación, ni las direcciones. La página de identidad y el paso de restablecimiento de la contraseña tampoco están protegidos.

Para quién está hecho este módulo

• Una tienda que recibe spam en el contacto, el registro o la newsletter a pesar de tener ya un CAPTCHA.
• Una tienda que quiere ver qué se rechaza y por qué, en lugar de descubrir el daño en su bandeja de entrada.
• Una agencia que gestiona varias tiendas y quiere ajustar la protección tienda por tienda.

Para quién no está hecho

• Una tienda sin formulario expuesto: no habría nada que proteger.
• Un comerciante que busca un cortafuegos de aplicaciones o protección contra ataques de denegación de servicio: no es la función del módulo.
• Un comerciante que espera cero spam: ningún módulo puede prometerlo, y un spammer humano puede rellenar un formulario correctamente.

¿Cómo se instala y se ajusta la protección paso a paso?

Instale el módulo, active la licencia, deje primero todos los formularios en observación y pase a la protección formulario por formulario después de leer el registro.

1. Compruebe los requisitos: PrestaShop 1.7.8, 8.0+ o 9.0+, PHP 7.4 o superior.
2. Instale el archivo desde el gestor de módulos. Los siete formularios nativos se crean para cada tienda y se añade la lista de dominios desechables.
3. Abra Configurar y active su licencia WePresta. Mientras la licencia no sea válida, el módulo sigue desactivado y los formularios no se comprueban.
4. Programe la tarea diaria de mantenimiento, con la dirección indicada en la configuración o la línea de comandos facilitada. Limpia el registro, los contadores, los bloqueos temporales caducados y los demás datos vencidos.
5. Abra Formularios y pulse Observar todo. Todas las comprobaciones se ejecutan, nada se rechaza y el registro guarda lo que se habría bloqueado.
6. Deje pasar unos días y abra el Registro de intentos bloqueados y el Panel. Los motivos indican si el bloqueo afectaría a bots o a clientes, sobre todo detrás de una dirección compartida por una empresa o un operador móvil.
7. Ejecute Probar mi protección. La herramienta lee la página del formulario como un visitante, comprueba los campos, el token y el script, prueba un envío directo sin campos para comprobar que se rechazaría y comprueba las claves del proveedor elegido.
8. Pase a la protección con Proteger todo, o formulario por formulario empezando por el contacto y la newsletter, después el registro, el inicio de sesión y las opiniones. Deje el formulario de cliente del pedido con sus límites amplios y sin tiempo mínimo.
9. Añada un CAPTCHA solo si un formulario sigue siendo objetivo, después de introducir sus claves y comprobar el botón Probar. Coloque las direcciones de sus socios en la lista de permitidos antes de endurecer los límites.

El módulo no escribe ningún archivo de tema: Classic y Hummingbird funcionan tal cual. Los derechos de los empleados se reparten entre consulta, gestión y datos. La documentación detalla cada ajuste.

¿Cómo se lee el registro y se actúa ante un rechazo?

Para cada intento, el registro da el formulario, el resultado, el motivo, la fecha, la dirección enmascarada y el dominio de correo, con acciones inmediatas en la línea.

Los motivos son explícitos: en el registro verá Campo trampa rellenado, Enviado demasiado rápido, Faltan campos de protección y Demasiados envíos desde esta dirección. Otras líneas muestran CAPTCHA fallido, Dirección en la lista de bloqueo, Correo electrónico en la lista de bloqueo o El dominio de correo electrónico no puede recibir correos electrónicos. Cada línea permite bloquear la dirección o su rango, permitir la dirección, bloquear el dominio de correo o levantar un bloqueo. Puede exportar el registro filtrado a CSV y vaciarlo.

El Panel ofrece la vista general: Permitido, Bloqueado, Tasa de bloqueo, Se habría bloqueado, Permitido sin comprobación y Exento, con un gráfico de 30 días y el detalle por formulario y por motivo.

La conservación es de 30 días por defecto y se ajusta en Registro y privacidad. La dirección no se guarda en claro: se enmascara y una huella con hash sirve para las listas y los límites. Se conserva el dominio de correo, nunca la dirección completa.

Un caso concreto: un formulario de contacto saturado por la noche

El formulario de contacto recibe cada noche una decena de mensajes idénticos. El registro muestra Campo trampa rellenado en el mismo rango de direcciones. Bloquee el rango con un clic desde la línea y compruebe al día siguiente que los envíos de sus clientes siguen pasando. Si cae un mensaje legítimo, la lista de permitidos lo restablece sin desactivar la protección.

¿Hace falta un CAPTCHA externo y cuál elegir?

No por defecto: las comprobaciones en el servidor funcionan sin clave ni cuenta de terceros, y un CAPTCHA externo se añade solo a un formulario que sigue siendo objetivo.

Cuando lo quiera, la elección se hace formulario por formulario: reCAPTCHA v2 (casilla o invisible) o v3 con umbral de puntuación, Cloudflare Turnstile, hCaptcha (normal, compacto o invisible) o Friendly Captcha. Introduzca sus claves en Configurar; el módulo nunca las muestra y el botón Probar 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 el primer contacto con el formulario. Si el proveedor no responde, usted elige dejar pasar el envío, registrado como no comprobado, o rechazarlo.

El consentimiento también se ajusta: 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 eligió pedir el acuerdo.

Un CAPTCHA externo tiene sus propias condiciones y su propia política de privacidad. Usted debe mencionarlo en su política y elegir el consentimiento adecuado; el módulo no certifica su conformidad con el RGPD.

¿Qué hace el módulo y cuáles son sus límites?

El módulo reduce los envíos automatizados y documenta cada rechazo, pero no promete cero spam ni sustituye a un cortafuegos o a un asesor jurídico.

• Ningún resultado prometido. Un spammer humano puede rellenar un formulario correctamente. El módulo hace costosos y visibles los envíos automatizados; no los elimina todos.
• El pedido queda fuera del filtro. No se comprueban el carrito, el pago, la confirmación ni las direcciones. El formulario de cliente del pedido mantiene límites amplios.
• Los visitantes comparten direcciones. Un límite demasiado estricto puede perjudicar a una empresa o a un operador móvil. El modo observación y la lista de permitidos sirven para comprobar antes de endurecer los límites.
• Sin certificación RGPD. El módulo ayuda a limitar los datos recogidos y ofrece hooks de exportación y borrado, pero no sustituye su política de privacidad ni un asesoramiento jurídico.
• Una licencia válida. Sin licencia válida, el módulo se desactiva: los formularios dejan de comprobarse, no se muestra ningún CAPTCHA y nada se registra. Los ajustes, listas y registro se conservan.
• Llamadas de red. La verificación de un CAPTCHA, la comprobación MX y la de los rastreadores de motores de búsqueda usan llamadas salientes; si el proveedor de un CAPTCHA no responde, se aplica el comportamiento elegido, y una consulta DNS fallida nunca rechaza un envío.

En una configuración multitienda, los ajustes, formularios, registro y estadísticas siguen siendo de cada tienda. Si su formulario de contacto viene de otro módulo, la ficha del formulario de contacto dinámico muestra un caso habitual; una auditoría de seguridad complementa la protección de los formularios.