reCAPTCHA para PrestaShop: protege tu tienda del spam y los bots

Última actualización: junio de 2026.

Una tienda PrestaShop funcionando sin CAPTCHA no es un riesgo hipotético: es un objetivo que el tráfico automatizado encuentra por sí solo. Los bots rastrean la web en busca de los endpoints estándar de los formularios de PrestaShop y, cuando encuentran los tuyos, empiezan a atacarlos sin descanso: registros falsos en AuthController, basura en el formulario de contacto, intentos de adivinar combinaciones de contraseña contra el inicio de sesión, avalanchas de correos de restablecimiento. Nada de esto requiere que nadie sepa que tu tienda existe. Los formularios vienen con PrestaShop, los bots conocen esos formularios y la instalación estándar de PrestaShop trae cero protección antibots en cualquiera de ellos.

Esta guía trata de cerrar esa brecha: qué hacen realmente los bots en una tienda PrestaShop, qué formularios concretos atacan y cómo CAPTCHA detiene cada caso. Si lo que te preocupa es la otra cara del problema, añadir protección sin ahuyentar a clientes reales con retos molestos, esa es una cuestión de conversión que abordamos por separado en reCAPTCHA sin molestar a clientes reales. Aquí nos centramos en la amenaza y la defensa.

Qué hacen realmente los bots en una tienda PrestaShop

"Spam y bots" suena impreciso hasta que lo ves golpeando tu propio back office. Así aparece en una instalación real de PrestaShop, relacionado con la parte de la tienda a la que daña.

El hilo común en todo esto es que el daño rara vez es una brecha espectacular. Es una degradación lenta: una base de datos de clientes en la que ya no puedes confiar, una bandeja de soporte que temes abrir, una reputación de correo que se hunde en silencio. CAPTCHA en los formularios adecuados corta la mayoría de estos abusos en la puerta. (Para el extremo más serio del espectro, como el relleno de credenciales, el abuso de pedidos y tarjetas, y los skimmers, CAPTCHA es una capa entre varias; consulta la lista completa de refuerzo de seguridad y la anatomía de un ataque al estilo Magecart.)

Qué formularios de PrestaShop proteger y cuáles dejar tranquilos

El impulso de "poner CAPTCHA en todas partes" es el equivocado. Los bots se concentran en un puñado de endpoints, y cada formulario que proteges añade un poco de fricción. Protege según dónde aterrizan los ataques, no por intuición.

Protege primero estos: ahí están los bots

• Formulario de registro. El objetivo número uno de los bots en cualquier tienda PrestaShop. Sin protección, es así como crece la montaña de cuentas falsas. No es negociable.
• Formulario de contacto. El segundo más atacado. Es lo que se interpone entre tú y una bandeja de Atención al cliente llena de ruido.
• Formulario de inicio de sesión. Evita que los intentos de fuerza bruta se conviertan tanto en un problema de carga del servidor como en un problema de cuentas comprometidas.

Protege después

• Restablecimiento de contraseña. Cierra el vector de inundación de correos de restablecimiento que deteriora tu reputación como remitente.
• Alta al boletín. Mantiene las suscripciones falsas fuera de tu lista.
• Reseñas de productos (si usas un módulo de reseñas). Los bots publican reseñas falsas para manipular valoraciones.

Déjalos tranquilos salvo que tengas un problema demostrado

• Pago. Añadir un CAPTCHA visible en la página de pago es un daño autoinfligido: aumenta el abandono en la página más valiosa de la tienda. Tócala solo si estás viendo fraude real durante el pago, y siempre con puntuación invisible (nunca una casilla). Estas compensaciones son exactamente el problema de "no molestar a clientes reales" que tratamos en la guía complementaria.
• Cuadro de búsqueda y añadir al carrito. Rara vez son un objetivo real; la fricción no compensa.

reCAPTCHA v2, v3 o hCaptcha: qué protección implementar

La versión que elijas cambia tanto lo difícil que es para un bot colarse como cuánto lo nota un cliente real. Hay tres opciones realistas para una tienda PrestaShop:

Para la mayoría de tiendas PrestaShop, la elección está entre v3 para puntuación invisible y v2 o hCaptcha para un reto explícito. El módulo actual mprrecaptcha te permite elegir reCAPTCHA v2, reCAPTCHA v3 o hCaptcha y configurar el umbral de puntuación de v3; no cambia automáticamente de v3 a v2 cuando las puntuaciones quedan en zona límite, así que gestionar puntuaciones bajas es una decisión de ajuste y rechazo, no un segundo reto. El umbral exacto que conviene fijar y cómo evitar bloquear a personas reales forman parte del trabajo de ajuste, que tratamos en la guía complementaria.

Cómo llevar CAPTCHA a los formularios de PrestaShop: la mecánica

PrestaShop no trae CAPTCHA, así que la protección pasa por un módulo. Lo importante es cómo se engancha, porque eso determina si realmente bloquea un envío o solo decora el formulario.

Paso 1: genera tus claves

Para reCAPTCHA, registra el sitio en www.google.com/recaptcha/admin; para hCaptcha, en el panel de hCaptcha. En ambos casos obtendrás una Site Key pública (se renderiza en la página) y una Secret Key privada (se usa en el servidor para verificar). Añade tanto tus dominios con www como sin www. Las claves están vinculadas al dominio: un dominio que no coincida puede romper la validación de CAPTCHA o bloquear envíos legítimos, así que registra un par independiente por entorno y comprueba que el formulario falla en modo cerrado (rechaza en lugar de dejar pasar silenciosamente los envíos) cuando el token no se verifica.

Paso 2: cómo se engancha un módulo bien hecho

Los ajustes importantes son proveedor, claves, formularios protegidos y umbral de v3.

En un módulo real, los hooks de visualización renderizan el widget y los hooks de acción rechazan el envío antes de que PrestaShop cree la cuenta, el mensaje o la suscripción. Estos son los hooks relevantes del código fuente de mprrecaptcha.

public function getHooks()
{
    return [
        'displayHeader',
        'displayFooter',
        'displayCustomerLoginFormAfter',
        'displayCustomerAccountForm',
        'displayNewsletterRegistration',
        'displayGDPRConsent',
        'actionContactFormSubmitBefore',
        'actionSubmitAccountBefore',
        'actionCustomerLoginBefore',
        'actionNewsletterRegistrationBefore',
    ];
}

Esta es la parte que separa la protección real del teatro. Un bot no rellena tu formulario a mano; envía un POST directo al controlador. Por eso la verificación tiene que ocurrir del lado del servidor, antes de que PrestaShop procese el envío, no solo como un widget dibujado en la página. El requisito clave es el mismo en todas las versiones: el token se valida en el servidor antes de procesar la cuenta, el mensaje de contacto, el inicio de sesión o el alta al boletín. Los nombres exactos de los hooks cambian según la rama: las versiones antiguas 1.6/1.7 usan flujos de front-controller y formularios distintos a los de 8/9, así que un módulo bien construido se conecta a los hooks Before validados que existan para tu versión objetivo (por ejemplo, los hooks de registro, formulario de contacto, inicio de sesión y envío del boletín). Use el hook que use, valida el token contra el endpoint siteverify de Google o hCaptcha y rechaza la solicitud antes de que se cree una cuenta o un mensaje. La parte de visualización se apoya en displayCustomerAccountForm, displayCustomerLoginFormAfter y displayHeader/displayFooter para inyectar el widget y cargar el script. Si un módulo solo renderiza la insignia pero no controla los hooks Before, un bot que envía un POST directo pasa de largo.

Paso 3: comprueba que realmente bloquea

No lo des por hecho: prueba. Envía cada formulario protegido como un cliente normal para confirmar que el uso legítimo sigue funcionando y luego revisa el panel del proveedor para confirmar que las verificaciones se están registrando. El fallo de configuración más común es un formulario que parece protegido, pero cuyo hook Before no está conectado, de modo que los bots pasan mientras tú crees que estás cubierto.

La elección del módulo específico para PrestaShop

Como la protección vive o muere en esos hooks del lado del servidor, el módulo que elijas importa más que la marca del CAPTCHA. Nuestro módulo mprrecaptcha (para PrestaShop 1.6 a 9) se creó exactamente para esto: admite reCAPTCHA v2, v3 y hCaptcha, y en cada rama compatible se engancha a los hooks reales de envío del lado del servidor de esa versión para registro, contacto, inicio de sesión y boletín, de modo que un POST directo de un bot se valida y se rechaza en el controlador, no simplemente se oculta en la página. ¿Qué significa eso para ti? Eliges desde el back office qué formularios proteger, dejas el pago sin fricción y los registros falsos y el spam de contacto dejan de llegar, sin editar archivos del tema ni tocar el núcleo, así que sobrevive a las actualizaciones. También expone un hook displayGDPRConsent para que el script de CAPTCHA pueda integrarse en tu flujo de consentimiento, algo importante en la UE (más abajo).

El punto del RGPD que no puedes saltarte

reCAPTCHA de Google carga JavaScript de Google y envía la IP y los datos de comportamiento del visitante a los servidores de Google, lo que bajo el RGPD es un tratamiento que necesita una base jurídica, y varias autoridades europeas de protección de datos (entre ellas la CNIL francesa) lo han señalado. Esto crea una tensión real para una tienda de la UE: bloquea reCAPTCHA hasta que haya consentimiento de cookies y tus formularios quedan desprotegidos para los visitantes que no consienten; cárgalo de todos modos y tendrás una exposición de cumplimiento. No hay una respuesta universalmente "correcta": es una decisión de riesgo. Dos vías prácticas: vincular CAPTCHA a tu mecanismo de consentimiento (para eso existe el hook displayGDPRConsent anterior) o esquivar por completo la transferencia de datos a Google usando hCaptcha, que no comparte datos con Google. Esto es una parte de un panorama de cumplimiento más amplio; la visión general para propietarios de tienda está en la guía de seguridad en lenguaje claro.

CAPTCHA es una capa, no todo el muro

CAPTCHA detiene el abuso automatizado de formularios: cuentas falsas, spam de contacto, inundaciones de restablecimiento, ruido de fuerza bruta. No lo detiene todo, y tratarlo como toda tu defensa es un error. Los bots distribuidos que rotan IPs, las avalanchas de tráfico y los actores maliciosos que ya han pasado el formulario necesitan otras capas:

• Bloqueo de bots malos e IPs para tráfico que no debería llegar a tus formularios en absoluto: consulta bloquear bots malos y tráfico no deseado y bloqueos de IP para visitantes problemáticos.
• Protección del lado de administración: CAPTCHA ayuda en el inicio de sesión del front office, pero el back office necesita autenticación de dos factores y política de contraseñas: 2FA y seguridad de administración.
• Carga generada por rastreadores que ningún CAPTCHA resuelve, como la avalancha de consultas de búsqueda facetada: sobrevivir a la avalancha de ?q=.
• Si algo consigue pasar: el plan de respuesta a incidentes en respuesta ante una filtración de datos.

La conclusión honesta: pon CAPTCHA en tus formularios de registro, contacto e inicio de sesión con un módulo que controle los hooks Before del lado del servidor, deja el pago tranquilo, aborda la cuestión del RGPD de forma deliberada y trata el resultado como una capa sólida de una tienda reforzada, no como la meta final. Hecho así, la degradación lenta de las cuentas falsas y los mensajes de soporte enterrados simplemente se detiene, y recuperas tus datos de clientes y tu bandeja de entrada.

Preguntas frecuentes

¿En qué formularios debería poner CAPTCHA realmente?

Protege donde están los bots, no en todas partes. Los tres primeros son el formulario de registro (el objetivo número uno: así crece la montaña de cuentas falsas), el formulario de contacto (mantiene utilizable tu bandeja de Atención al cliente) y el formulario de inicio de sesión (detiene el ruido de fuerza bruta). Siguiente nivel: restablecimiento de contraseña, alta al boletín y reseñas de productos si usas un módulo de reseñas. Deja el pago tranquilo salvo que tengas fraude demostrado: un CAPTCHA visible ahí aumenta el abandono en tu página más valiosa, y si tienes que hacerlo, usa solo puntuación invisible, nunca una casilla.

reCAPTCHA v2, v3 o hCaptcha: ¿cuál debería elegir?

v3 es invisible y puntúa el comportamiento de 0.0 a 1.0 con un umbral que tú defines, lo que encaja con formularios de mucho tráfico o sensibles a la conversión, pero requiere un ajuste cuidadoso para no rechazar a personas reales con puntuaciones bajas. v2 y hCaptcha muestran un reto explícito, adecuado para formularios de contacto y registro donde un pequeño clic es aceptable. El punto diferencial de hCaptcha para tiendas de la UE es que no envía datos a Google. El módulo mprrecaptcha admite los tres y te permite definir el umbral de puntuación de v3; no cambia automáticamente de v3 a v2 en puntuaciones límite, así que gestionar puntuaciones bajas es una decisión de ajuste y rechazo.

Mi formulario parece protegido, pero el spam sigue entrando: ¿qué falla?

Casi siempre la verificación es decorativa, no obligatoria. Un bot no rellena tu formulario a mano: envía un POST directo al controlador, así que si el módulo solo renderiza el widget en la página pero no controla los hooks Before del lado del servidor (los hooks de registro, contacto, inicio de sesión y envío del boletín), un POST directo pasa sin obstáculos. La protección real valida el token contra el endpoint siteverify del proveedor antes de que se cree la cuenta, el mensaje o la suscripción. Pruébalo: envía cada formulario como un cliente normal para confirmar que sigue funcionando y luego revisa el panel del proveedor para confirmar que las verificaciones se están registrando.

¿Por qué CAPTCHA "deja de funcionar" cuando muevo dominios o añado www?

Las claves de reCAPTCHA y hCaptcha están vinculadas al dominio. Si tu Site Key y tu Secret Key se registraron para un host, no validarán en otro, así que una entrada www / sin www que no coincida o falte puede romper la validación o bloquear envíos legítimos. Añade tanto tus dominios con www como sin www a la clave y registra un par de claves separado por entorno (staging frente a producción). Confirma también que el formulario falla en modo cerrado: rechaza envíos cuando el token no se verifica, en lugar de dejarlos pasar en silencio.

¿Usar Google reCAPTCHA es un problema de RGPD para una tienda de la UE?

Es una decisión de riesgo real, no un sí/no cerrado. reCAPTCHA carga JavaScript de Google y envía la IP y el comportamiento del visitante a Google, lo que es un tratamiento que necesita una base jurídica según el RGPD, y varias autoridades de la UE (entre ellas la CNIL francesa) lo han señalado. Dos vías prácticas: integrar CAPTCHA en tu mecanismo de consentimiento (el hook displayGDPRConsent existe para esto) o evitar por completo la transferencia de datos a Google usando hCaptcha. Elijas lo que elijas, nunca cargues el script de CAPTCHA antes del consentimiento si lo estás tratando como no esencial.

¿CAPTCHA sustituye a otras medidas de seguridad?

No: es una capa. CAPTCHA detiene el abuso automatizado de formularios: cuentas falsas, spam de contacto, inundaciones de correos de restablecimiento, ruido de fuerza bruta. No detiene bots distribuidos que rotan IPs, avalanchas de tráfico ni a nadie que ya haya pasado el formulario. Combínalo con bloqueo de bots malos e IPs para tráfico que no debería llegar a tus formularios, autenticación de dos factores y una política de contraseñas en el back office, y un plan de incidentes si algo consigue pasar. CAPTCHA en registro, contacto e inicio de sesión es una capa sólida de una tienda reforzada, no la meta final.