Cómo evitar el spam en los formularios de PrestaShop (sin castigar a tus clientes)

El día que tu buzón dejó de servir

Hay un momento concreto en el que una tienda deja de leer su formulario de contacto. No es una decisión: simplemente, un día llegan cuarenta mensajes con enlaces a casinos, y al siguiente se abren por encima, y a la semana ya nadie los mira.

El problema no es el ruido. El problema es el mensaje número cuarenta y uno, el del cliente que preguntaba si el producto le sirve para su caso y que ya no va a comprar porque nadie le contestó.

Esta guía va de cerrar esa puerta sin cerrársela a los clientes. Está escrita para PrestaShop 8 y 9, pero casi todo aplica a cualquier tienda.

Por qué el reCAPTCHA gratuito no basta

Es el primer consejo que da todo el mundo, y no está mal. Está incompleto.

Los bots modernos no “resuelven” el captcha: lo esquivan. Un script que hace POST directo al endpoint de PrestaShop nunca ejecuta el JavaScript de Google, así que no genera token. Si tu validación solo comprueba el token cuando existe, el bot pasa por el hueco. Y si la haces obligatoria, cualquier cliente con JavaScript bloqueado o una extensión de privacidad se queda fuera sin entender por qué.

Hay un segundo problema, menos comentado y más serio: reCAPTCHA envía datos del visitante a Google antes de que haya consentido nada. La Agencia Española de Protección de Datos considera que los servicios de este tipo requieren base jurídica y transparencia, y varias autoridades europeas han sancionado su uso indiscriminado. Si lo cargas en todas las páginas por si acaso, tienes un problema de cookies además de uno de spam.

Y hay un tercero, puramente práctico: subir la exigencia castiga a quien menos lo merece. El usuario que más falla los captchas visuales es el que peor ve, el que va con prisa desde el móvil y el que tiene la conexión mala. Es decir, gente que compraría.

La conclusión no es “no uses reCAPTCHA”. Es que una sola capa no aguanta, y que la capa que molesta al cliente debería ser la última, no la primera.

Los cuatro sitios por donde entra

En PrestaShop el abuso no llega por un formulario, llega por cuatro, y cada uno recibe algo distinto:

Contacto. Spam publicitario clásico y campañas de enlaces. Es el más visible y el que primero se satura.

Registro de clientes. Cuentas falsas creadas en masa. Molesta menos de entrada, pero ensucia las estadísticas, infla la base de datos y, si tienes emails de bienvenida automáticos, puede quemarte la reputación de envío.

Newsletter. Suscripciones basura con direcciones inventadas. Cada rebote que acumulas empeora la entregabilidad del resto de tus correos, incluidos los de confirmación de pedido.

Recuperación de contraseña. El más ignorado y el más peligroso. Un script que pide recuperación mil veces contra direcciones reales convierte tu tienda en la herramienta de acoso de otro, y tu dominio en el que aparece en la bandeja de entrada de la víctima.

A esto se añaden, según la tienda, el formulario de direcciones y el de reseñas de producto.

Ordena por dónde te duele. Casi nadie necesita blindar los seis a la vez, y hacerlo de golpe es la forma más rápida de romper algo sin saber cuál.

La capa que casi nadie pone y filtra más: el señuelo

Un honeypot es un campo que existe en el HTML, está oculto para las personas y no debería llegar nunca relleno. Los bots que rellenan formularios de forma automática lo rellenan porque leen el DOM, no la pantalla.

En una plantilla de PrestaShop:

<div class="cd-hp" aria-hidden="true">
  <label for="cd_website">No rellenes este campo</label>
  <input type="text" id="cd_website" name="cd_website" tabindex="-1" autocomplete="off">
</div>

Y en el CSS, fuera de la vista sin usar display:none, que algunos bots detectan:

.cd-hp {
  position: absolute;
  left: -9999px;
  height: 0;
  overflow: hidden;
}

La validación en el controlador es una línea:

if (Tools::getValue('cd_website') !== '') {
    // Se descarta en silencio: responder "spam detectado" le dice al bot
    // exactamente qué cambiar en el siguiente intento.
    Tools::redirect('index.php?controller=contact&submitted=1');
}

Fíjate en el detalle del comentario, porque es lo que separa un honeypot que funciona de uno que dura dos semanas: si le dices al bot que lo has pillado, se adapta. Un envío bloqueado debe parecerse a un envío correcto.

Tres advertencias sobre el aria-hidden y el tabindex="-1": son obligatorios. Sin ellos, un lector de pantalla anuncia el campo y una persona ciega intentará rellenarlo, con lo que habrás construido un filtro que bloquea exactamente a quien no debe.

Control de tiempo: nadie escribe tan rápido

La segunda capa es todavía más barata. Al pintar el formulario, guarda cuándo se pintó. Al recibirlo, mira cuánto ha pasado.

// Al mostrar el formulario
$momento = time();
$firma = hash_hmac('sha256', (string) $momento, _COOKIE_KEY_);
// se envían como campos ocultos: cd_t y cd_s

// Al recibirlo
$momento = (int) Tools::getValue('cd_t');
$firma = (string) Tools::getValue('cd_s');
$esperada = hash_hmac('sha256', (string) $momento, _COOKIE_KEY_);

// La firma evita que el bot mande una marca de tiempo inventada.
if (!hash_equals($esperada, $firma) || (time() - $momento) < 3) {
    Tools::redirect('index.php?controller=contact&submitted=1');
}

La firma no es opcional. Sin ella, el campo de tiempo lo controla quien envía, y basta con mandar una marca de hace un minuto. Es el error típico de las implementaciones caseras: ponen el control temporal y lo dejan manipulable.

Tres segundos es conservador. Un formulario de contacto real rara vez se rellena en menos de quince, pero conviene ir holgado: alguien que pega un texto ya escrito y le da a enviar puede tardar cinco.

Limitar intentos, y por qué la sesión no vale

La tercera capa frena la fuerza bruta:

$ip = Tools::getRemoteAddr();
$desde = date('Y-m-d H:i:s', strtotime('-1 hour'));

$intentos = (int) Db::getInstance()->getValue(
    'SELECT COUNT(*) FROM `' . _DB_PREFIX_ . 'cd_envios`
      WHERE ip_hash = "' . pSQL(hash('sha256', $ip . _COOKIE_KEY_)) . '"
        AND creado_en > "' . pSQL($desde) . '"'
);

if ($intentos >= 5) {
    Tools::redirect('index.php?controller=contact&submitted=1');
}

Dos decisiones ahí que conviene entender:

El contador va en base de datos, no en sesión. Un bot no guarda cookies, así que cada envío le abre una sesión nueva y el contador nunca sube. Guardarlo en sesión es un límite que solo se aplica a los clientes legítimos, que es justo al revés de lo que quieres.

La IP se guarda como hash, no en claro. Una dirección IP es un dato personal, y guardarla en bruto para siempre en una tabla de spam es un tratamiento que tendrías que justificar. El hash con una sal —aquí, la clave de cookies de la tienda— te da lo que necesitas, que es contar, sin quedarte lo que no necesitas, que es saber quién.

Cuidado con las tiendas detrás de CDN o proxy: si no lees bien la cabecera del cliente real, todos tus visitantes comparten IP y el límite los bloquea a todos en cuanto pasen cinco. Comprueba qué devuelve Tools::getRemoteAddr() en tu instalación antes de fiarte.

Qué no funciona

Vale la pena decirlo, porque son consejos que circulan mucho:

Bloquear por país. El spam viene de servidores alquilados, y se alquilan en cualquier sitio. Bloqueando países pierdes clientes reales y no bloqueas casi nada.

Listas negras de dominios de correo. Se quedan viejas en semanas. Y el spammer que usa gmail.com no aparece en ninguna.

Preguntas tipo “¿cuánto es 2+2?”. Un script las resuelve mejor que una persona. Solo frenan a los bots de hace quince años.

Ocultar el formulario tras un clic. Frena a los bots que no ejecutan JavaScript, que son precisamente los que ya frenaba el honeypot, y estorba a los clientes que van desde el móvil.

Cambiar el nombre de los campos. Sirve una temporada contra scripts genéricos que buscan name="message". Contra cualquiera que mire tu HTML una vez, no.

Mide antes de apretar

Esta es la parte que casi nadie hace y la que más disgustos evita.

Cuando montes las capas, registra qué bloqueas y por qué motivo durante al menos dos semanas antes de subir la exigencia. Lo que buscas en ese registro no es cuánto spam paras —eso lo notas en el buzón— sino si estás parando algo que no deberías.

La señal de alarma es un pico de bloqueos por control temporal: suele significar que alguien pega texto preparado y envía rápido, y eso son clientes, no bots. La segunda señal es que los bloqueos por límite de intentos se concentren en pocas IPs con muchos envíos legítimos: ahí tienes el problema del proxy.

Guarda el motivo, la fecha y el hash de IP. Nada más. Y bórralo pasados noventa días: un registro de bloqueos que crece indefinidamente es una base de datos de comportamiento de tus visitantes que no te aporta nada y sí te obliga a explicarla.

Cuándo compensa un módulo

Todo lo anterior se puede montar a mano. La pregunta razonable es si merece la pena.

Hazlo a mano si tienes un solo formulario problemático, sabes tocar plantillas y controladores, y no te importa revisarlo cuando actualices PrestaShop. Son unas horas y aprendes cómo funciona tu tienda.

Un módulo compensa si te entra por varios formularios a la vez, necesitas el registro de bloqueos sin montártelo, o —el caso más común— no quieres que la próxima actualización de PrestaShop se lleve por delante tus cambios en las plantillas. Eso es lo que de verdad se paga: que siga funcionando dentro de un año.

Nosotros vendemos uno, Croqueta Shield, que hace exactamente esto por capas sobre los seis formularios, con reCAPTCHA v3 y reserva en v2, y con el visor de bloqueos en el panel. Lo digo con la misma honestidad con la que he escrito el resto: si tu problema es solo el formulario de contacto y te apañas con el código de arriba, no lo necesitas.

Metodología y fuentes

Lo descrito aquí procede del trabajo de mantenimiento sobre tiendas PrestaShop 8 y 9 y del código del propio módulo. Los fragmentos están simplificados para que se entiendan: en producción hay que añadir la gestión de errores y las comprobaciones de token de PrestaShop.

No aparece ni una cifra de “porcentaje de spam bloqueado” a propósito. Cualquier número de ese tipo depende del volumen y del tipo de abuso de cada tienda, y darlo como si fuera general sería inventárselo.

Referencias consultadas:

• Documentación oficial de PrestaShop sobre el módulo reCAPTCHA
• Guía de reCAPTCHA v3 de Google para desarrolladores
• Agencia Española de Protección de Datos: guía sobre el uso de cookies

Revisado: 20 de agosto de 2026.