Protección contra bots, límites de solicitudes y CAPTCHA en PrestaShop

Qué haríamos

Identificaríamos el recorrido que falla y las solicitudes que lo provocan antes de instalar otra capa de protección. La vía adecuada depende de tu tienda actual: versiones de PrestaShop y PHP, alojamiento y configuración de proxies, tema, módulos, integraciones, datos registrados, mercados y personas que revisarán los rechazos. Conserva los controles que funcionan y comprueba si un módulo instalado ya proporciona el paso que falta.

Si la tienda tiene dificultades para servir páginas, empieza donde se puedan detener las solicitudes antes de PHP. Si hay envíos no deseados sin problemas de capacidad, empieza por el formulario afectado y su validación en el servidor. Si se cuestiona una cuenta o un pedido, revisa las pruebas antes de restringir el acceso. La tabla de decisión siguiente te ayuda a elegir la capa inicial.

Reproduce los recorridos pertinentes en una copia de pruebas privada con tu tema, proceso de compra y módulos reales, aislada de correos a clientes, pagos reales y exportaciones de preparación de pedidos. Guarda la configuración actual, ensaya las pruebas de rechazo y recuperación e introduce después el cambio en una ventana de producción acordada. Utiliza una prueba acotada en producción para comprobar direcciones reales de proxies, tráfico de rastreadores y comportamiento perimetral que el entorno de pruebas no puede reproducir, con un revisor designado y una forma de revertir la regla.

Si necesitas evaluar la exposición, el servicio PrestaShop Security Audit & Hardening Report ofrece hallazgos priorizados y un plan de corrección; la implementación se define por separado.

Identifica las solicitudes antes de bloquearlas

Empieza por la acción afectada: páginas de categoría lentas, inicios de sesión repetidos, registros falsos, mensajes de spam o un aumento de carritos vacíos. Registra las marcas de tiempo, rutas, argumentos de consulta, códigos de estado, tiempos de respuesta y direcciones de red implicadas. Compáralos con los procesos PHP, la actividad de la base de datos y los pedidos legítimos.

Los rastreadores de búsqueda, los sistemas de vista previa de enlaces sociales, las llamadas de retorno de pagos, la monitorización y las tareas programadas pueden ser automatizaciones útiles. La extracción de datos, la reutilización masiva de credenciales robadas, las pruebas de vulnerabilidades, las cuentas falsas y los envíos abusivos necesitan controles diferentes. Un agente de usuario declarado, una dirección VPN, una red de alojamiento o un país no demuestran abuso.

Usa los registros de solicitudes para medir su frecuencia

Revisa los registros del servidor web y del servicio perimetral. Para un registro de acceso combinado convencional, estos ejemplos cuentan las solicitudes registradas según el primer campo de dirección y la ruta solicitada. Confirma primero el formato real del registro; una dirección de proxy en el primer campo requiere otro tratamiento.

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Estos totales abarcan el archivo, no un intervalo definido de frecuencia. Filtra una ventana de tiempo adecuada y separa los recursos estáticos, las solicitudes de páginas, los envíos de formularios y los reintentos antes de elegir los límites. Los sondeos genéricos como /wp-login.php o /.env merecen investigación, pero no demuestran una intrusión exitosa.

Las estadísticas nativas pueden dar pistas, según los módulos estadísticos instalados. En Estadísticas, revisa los paneles disponibles de Visitantes en línea, Origen de los visitantes, Páginas no encontradas y Páginas más vistas para detectar cambios que merezca rastrear en los registros de solicitudes. La tabla de conexiones no es un registro HTTP completo: puede excluir bots reconocidos y los registros de conexión se reutilizan durante un intervalo de 30 minutos. La siguiente consulta de solo lectura cuenta las sesiones de conexión IPv4 registradas de la tienda 1 con el prefijo de ejemplo ps_.

SELECT INET_NTOA(c.ip_address) AS recorded_ipv4,
       COUNT(*) AS recorded_sessions
FROM ps_connections AS c
WHERE c.id_shop = 1
  AND c.date_add > DATE_SUB(NOW(), INTERVAL 1 DAY)
GROUP BY c.ip_address
ORDER BY recorded_sessions DESC
LIMIT 50;

Cambia el prefijo de tablas y el ámbito de tienda para que coincidan con tu instalación. Ejecuta los informes de solo lectura mediante Parámetros avanzados > Base de datos > Gestor SQL o una herramienta de base de datos autorizada. Este almacenamiento numérico antiguo de IP no es un informe completo de tráfico IPv6. Los metadatos de navegador interpretados en las tablas de invitados no son un registro de User-Agent sin procesar.

Las tablas de visitantes de terceros también pueden eliminar observaciones duplicadas. Contar esas filas mide registros recopilados, no solicitudes, visitas ni una huella fiable de dispositivo. Correlaciónalas con los registros de solicitudes antes de actuar.

Convierte las señales de alerta en un diagnóstico comprobable

Conserva un breve registro del incidente con un ejemplo de solicitud sin datos sensibles, su zona horaria, la ruta afectada y el efecto observado. Facilita al alojamiento y al desarrollador el mismo intervalo para comparar eventos perimetrales, registros de acceso y actividad de la aplicación sin intercambiar registros completos de clientes.

Verifica la identidad de los rastreadores y las direcciones del proxy

Un bot puede enviar Googlebot en su User-Agent. Para eximir un rastreador, coteja los rangos IP publicados vigentes que correspondan o usa DNS inverso confirmado por resolución directa.

1. Obtén la IP original del cliente de un campo de registro fiable.
2. Haz una resolución inversa.
3. Comprueba el sufijo de dominio documentado del operador en un límite de dominio real. Un nombre de host que termina en googlebot.com.example.net no pertenece a Google.
4. Resuelve directamente el nombre de host devuelto y confirma que la dirección original figura entre los resultados.
5. Guarda en caché y actualiza los datos de verificación, y gestiona los fallos de consulta sin crear silenciosamente una exención permanente.

Usa el procedimiento de verificación de rastreadores de Google para sus categorías de rastreadores y los archivos actuales de rangos. Otros operadores tienen sus propios procedimientos. La verificación establece la identidad, no una capacidad ilimitada de generación de páginas.

Configura los proxies inversos de confianza antes de activar límites por IP. El origen debe aceptar cabeceras de dirección de cliente reenviadas solo desde infraestructura de confianza, y esta debe sobrescribir los valores entrantes no fiables. La validación sintáctica de IP no autentica CF-Connecting-IP, X-Real-IP ni X-Forwarded-For.

Prueba la dirección que ven el servicio perimetral, el servidor web, PHP y tu integración de bloqueo. Comprueba IPv4 e IPv6. Una configuración incorrecta puede agrupar a todos los clientes bajo la dirección de un proxy o permitir que los clientes elijan la dirección registrada.

Para las reglas por país, confirma cómo se obtiene la ubicación. Una cabecera de país de un servicio perimetral de confianza, un adaptador GeoIP actualizado y una cookie de país guardada tienen distinta fiabilidad. No des por hecho que una API GeoIP antigua funciona con código GeoIP2 moderno.

Elige los controles en la capa adecuada

PrestaShop puede generar robots.txt en Parámetros de la tienda > Tráfico & SEO > SEO y URLs. Revisa el contenido generado y tus rutas reales. No pongas secretos en robots.txt ni trates una ruta no permitida como privada. La inclusión en el sitemap depende de tu módulo de sitemap y su configuración.

Mantén en el inventario de rutas los webhooks de pago, la validación de pedidos, los retornos de 3-D Secure y la monitorización. Registra la finalidad, método, respuesta esperada y responsable de cada ruta antes de cambiar su tratamiento. Verifica las firmas de los proveedores y sus requisitos actuales de entrega. Una excepción amplia para cualquier cliente que afirme ser de pagos es insegura.

Un límite de solicitudes debe utilizar un intervalo explícito y una carga de trabajo medida. Configura un estado de rechazo adecuado, normalmente HTTP 429 para limitar la frecuencia, y una respuesta de reintento utilizable. Considera las redes de oficinas, operadores móviles, herramientas de accesibilidad y clientes automatizados legítimos. Cuenta la acción que quieres limitar: incluir imágenes y scripts en una política de acceso puede hacer que una carga normal de página consuma el cupo. El tráfico distribuido también puede sobrecargar una ruta aunque cada dirección permanezca por debajo de su límite individual.

Para límites de aplicación, tareas de actualización de rastreadores verificados, desafíos JavaScript y la protección independiente de capacidad, utiliza la página de ayuda de Security Revolution; su cortafuegos de solicitudes usa la monitorización de forma predeterminada, así que activar una función no demuestra por sí solo que se esté aplicando el bloqueo.

Contén las solicitudes costosas de búsqueda por facetas

Una solicitud de categoría como /category-slug?q=Brand-Brand-A/Color-Red puede activar trabajo de filtrado. Muchas combinaciones distintas pueden generar poca reutilización de caché mientras ocupan procesos PHP y conexiones de base de datos. Confirma el coste en tus propios registros y perfiles de solicitudes.

Desactivar ps_facetedsearch puede eliminar su interfaz y reducir el trabajo de filtrado. No impide que los clientes soliciten URL que ya conocen ni que esas solicitudes lleguen al controlador de categorías. Bloquear indiscriminadamente todo argumento q también puede romper búsquedas, rutas de módulos, API y filtros guardados por clientes.

Ejemplo práctico: servidor ocupado, ventas sin cambios

Supón que los registros muestran combinaciones cambiantes de marca y color en una categoría mientras los procesos PHP siguen ocupados. Agrupa las solicitudes por categoría y por URL completa: una lista larga de URL distintas puede ocultar una misma ruta costosa. Compara las respuestas filtradas y sin filtrar y pregunta al alojamiento dónde se consume el tiempo. Si las combinaciones rara vez se repiten, añadir cada respuesta a una caché de páginas puede aumentar el almacenamiento y las escrituras sin mucha reutilización.

Prueba la regla en esa categoría confirmada, conservando como controles un enlace filtrado directo representativo y una sesión normal de filtrado en el navegador. Si aumentan los desafíos perimetrales pero el trabajo del origen sigue siendo alto, inspecciona las solicitudes que aún pasan: rastreadores verificados, clientes con el indicador AJAX, desafíos superados o tráfico directo al origen. Esas pruebas determinan el siguiente cambio; un mayor número de desafíos no demuestra por sí solo que haya desaparecido el cuello de botella.

Crea una regla perimetral de alcance limitado

1. Enumera las rutas reales de categorías con facetas, incluidos subdirectorios de tienda, idiomas y rutas reescritas. Empieza por un conjunto explícito pequeño.
2. Selecciona las solicitudes GET que lleven el argumento de faceta pertinente. Prueba también argumentos vacíos y valores repetidos.
3. Decide cómo se tratan los rastreadores verificados dentro de esta regla concreta. No crees una omisión general de otras reglas de seguridad.
4. Comprueba el filtrado AJAX. Devolver una página HTML de desafío a una solicitud que espera JSON puede romper la interfaz.
5. Prueba un Managed Challenge y revisa el comportamiento de los clientes y la carga que sigue llegando al origen antes de ampliar la cobertura.

Esta expresión ilustra una tienda cuya ruta de categoría confirmada es exactamente /en/12-home-accessories. Utiliza solo rutas confirmadas para tu tienda. Si las facetas se codifican en una ruta reescrita en lugar de un argumento q, esta expresión no coincidirá con ellas; crea y prueba una condición de coincidencia para esas rutas reales.

http.request.method eq "GET"
and http.request.uri.path eq "/en/12-home-accessories"
and len(http.request.uri.args["q"]) >= 0
and not cf.client.bot
and not any(lower(http.request.headers["x-requested-with"][*])[*] eq "xmlhttprequest")

La comparación con una clave ausente da falso cuando q no existe. Consulta el comportamiento de los valores del lenguaje de reglas de Cloudflare. El indicador AJAX se puede falsificar y algunos clientes AJAX legítimos lo omiten. Cualquier excepción basada en él deja una vía de evasión disponible. Una excepción para bots verificados también deja que la carga de ese rastreador llegue al origen.

Las reglas personalizadas y Managed Challenge están disponibles en todos los planes de Cloudflare. Las coincidencias con expresiones regulares requieren Business o Enterprise; la acción Log de reglas personalizadas requiere Enterprise. Consulta la disponibilidad de reglas personalizadas. Sin Log, usa la analítica disponible y una prueba controlada de alcance limitado.

Usa cf.bot_management.score solo si dispones de Bot Management. Una posible prueba se dirige a puntuaciones superiores a 1 e inferiores a 30; trata la puntuación 1 por separado si procede. Las puntuaciones describen automatización, no intención maliciosa. La antigua puntuación de amenaza no es un sustituto. Comprueba las interacciones entre funciones de Cloudflare antes de combinar controles. Bot Fight Mode gratuito se aplica a todo el dominio y no puede omitirse mediante reglas personalizadas.

Los desafíos pueden requerir interacción, cookies o JavaScript. Prueba enlaces directos, navegadores móviles y herramientas de privacidad. Los visitantes que superan un desafío aún pueden generar trabajo en el origen.

Cierra la vía de acceso directo al origen

Pasa los nombres de host web públicos por el proxy del servicio perimetral elegido. Mantén los registros DNS de correo y otros servicios no HTTP configurados para su servicio real. Audita los registros que revelan el origen web y restringe el acceso HTTP/HTTPS al origen a las direcciones publicadas actuales del servicio perimetral más el acceso operativo estrictamente justificado. Conserva la renovación de certificados, las comprobaciones de estado y el acceso para revertir cambios. Usa HTTPS válido entre el servicio perimetral y el origen.

Revisa el acceso de rastreadores, la visibilidad en búsquedas y las visitas útiles de referencia después de los cambios. Si el filtro existente funciona para los compradores, consérvalo mientras validas los controles de tráfico. Considera otra arquitectura de filtros cuando la navegación del catálogo también necesite cambios, con páginas de destino elegidas expresamente en lugar de combinaciones indexables arbitrarias. Puede reducir el descubrimiento de combinaciones arbitrarias, pero las URL antiguas y los puntos de acceso AJAX siguen necesitando controles; utiliza la página de ayuda de Filter Revolution para el flujo de rutas y páginas SEO de ese módulo.

Protege el servidor de origen sin un WAF perimetral

Usa límites del servidor cuando controles Apache o Nginx, o pide a tu alojamiento que los aplique. Apache .htaccess admite condiciones de solicitud adecuadas cuando se permiten overrides; módulos de limitación como mod_evasive requieren su configuración compatible de servidor o host virtual. Los bloqueos por User-Agent pueden expresar una política de rastreadores, pero los agentes vacíos o con un nombre concreto no son maliciosos por naturaleza.

En Nginx, limit_req_zone pertenece al contexto http. Aplica limit_req donde se procesa realmente la solicitud costosa. Las URL amigables pueden redirigir internamente a index.php, así que prueba la ubicación final y los argumentos de ruta. Los siguientes son ejemplos de directivas para integrar en una configuración existente, no un bloque de servidor completo de sustitución:

# http context: illustrative measured-policy starting point
limit_req_zone $binary_remote_addr zone=shop_requests:20m rate=10r/s;

# In the applicable request-processing context
limit_req zone=shop_requests burst=40;
limit_req_status 429;
limit_req_dry_run on;

Utiliza la referencia de limitación de solicitudes de Nginx para comprobar la compatibilidad y herencia de directivas. Con limit_req_dry_run on, las solicitudes excedentes se registran, pero no se rechazan. Tras revisar los registros y los recorridos legítimos, establece limit_req_dry_run off, ejecuta una prueba de configuración y recarga solo una configuración válida, conservando la anterior para revertir. Las rutas de acceso y filtros costosos pueden necesitar políticas separadas; una expresión regular para /search no cubre todas las solicitudes de categoría con q.

Para fail2ban, registra un evento explícito de fallo de autenticación en el servidor y prueba el filtro con accesos reales fallidos y correctos. Incluye un error normal de contraseña seguido de un reintento correcto y confirma cómo una persona autorizada libera un bloqueo erróneo. El acceso nativo de clientes puede devolver un formulario con error y HTTP 200. Un filtro que busque solo POST de acceso con respuesta 401 o 403 puede pasar por alto los fallos. Nunca registres contraseñas ni secretos de CAPTCHA.

Una redirección de aplicación acotada como alternativa

Si una URL directa de facetas seleccionada debe resolver a su categoría sin filtros, un desarrollador puede implementar una redirección temprana del Dispatcher. Sigue iniciando PHP y es menos útil frente al agotamiento de conexiones que un control perimetral o de servidor.

1. Resuelve o identifica explícitamente la categoría de la tienda y el idioma actuales. Limita la intervención a solicitudes GET con el argumento de faceta pertinente.
2. Excluye la búsqueda y las rutas de módulos y API. Si conservas las solicitudes AJAX, prueba el indicador real y acepta que los bots pueden copiarlo.
3. Analiza REQUEST_URI, elimina solo q y reconstruye la consulta con http_build_query(). Conserva los demás argumentos, la ruta base de la tienda y el prefijo de idioma.
4. Usa el origen configurado de la tienda, evita bucles y detén el procesamiento después de la redirección. En los demás casos, continúa el despacho normal.
5. Prueba con una redirección temporal. Usa un 301 permanente solo si eliminar el destino filtrado es intencionado. Revisa los overrides existentes de Dispatcher y reconstruye el índice de clases correspondiente tras el despliegue.

Los enlaces guardados pierden los filtros seleccionados dentro de ese ámbito. Revisa las páginas de filtros indexadas valiosas y asígnales un destino deliberado en vez de suponer que ninguna combinación tiene valor en buscadores. Combinar una redirección con una regla perimetral sigue eliminando el filtro cuando se permite pasar al cliente.

Protege los formularios con validación del servidor

Elige los formularios según el abuso observado: registro, contacto, acceso, restablecimiento de contraseña, newsletter, reseñas o proceso de compra. La búsqueda y añadir al carrito también pueden sufrir abuso de recursos, aunque un CAPTCHA interactivo no es automáticamente la solución adecuada.

No todos los formularios estándar incluyen CAPTCHA, pero sí disponen de controles. La recuperación de contraseña incluye comprobaciones de tiempo; algunas versiones del módulo oficial de contacto utilizan un campo trampa y un token con caducidad. Conserva esos controles al añadir otra capa. Prueba el autocompletado del navegador y las herramientas de asistencia con cualquier campo trampa añadido: un campo oculto rellenado merece validación, no una suposición sobre quién lo envió.

Selecciona el proveedor y el modo, crea las claves correspondientes en su consola e introdúcelas en la configuración del módulo. Activa la protección de los formularios previstos y ejecuta después las pruebas de envío válido y rechazo siguientes. La clave del sitio es pública; conserva el secreto en el servidor. Utiliza el tipo de clave, entorno y configuración de host correctos. Registrar un dominio raíz en reCAPTCHA cubre ese dominio y sus subdominios de primer nivel, incluido www; los dominios no relacionados necesitan su propia configuración permitida. Sigue las normas de dominios de Google y las normas específicas de cualquier otro proveedor.

El servidor debe verificar el token y el contexto esperado antes de crear una cuenta, enviar correo, suscribir una dirección o autenticar a un cliente. Comprueba el éxito, el host, la acción y la puntuación cuando corresponda. Nunca confíes solo en un indicador de éxito del cliente ni en una insignia mostrada.

Trata el acceso de clientes y el de empleados como requisitos separados. Un desafío que funciona en la tienda no demuestra nada sobre el acceso al back office; la autenticación del personal necesita comprobaciones y un procedimiento de recuperación propios.

Para desarrolladores, comprueba el contrato exacto del núcleo en cada versión compatible. El registro moderno combina los resultados de actionSubmitAccountBefore como booleanos. El acceso nativo de clientes llama a actionAuthenticationBefore pero no usa su valor de retorno como rechazo. Registrar simplemente un hook con nombre parecido no basta. El acceso durante la compra, el registro de invitados, los formularios AJAX y los temas personalizados necesitan su propia cobertura de rutas.

El registro nativo de cuentas no exige generalmente un enlace de activación por correo. El correo de bienvenida, la verificación de cuenta y la doble confirmación de newsletter son flujos separados.

Para ajustes del proveedor, formularios compatibles, alternativa opcional de v3 a v2 y carga condicional de scripts, utiliza la página de ayuda de reCAPTCHA & hCaptcha Protection. La cobertura indicada incluye contacto, acceso de clientes, registro y newsletter, seleccionados por separado; esas opciones no certifican todas las integraciones de compra, restablecimiento de contraseña o reseñas. La alternativa indicada muestra una casilla en el siguiente intento tras una puntuación baja y necesita otro par de claves. Comprueba que tu versión instalada la ofrece y que el cliente puede completar ese siguiente intento.

Ejemplo práctico: registro protegido, cuentas falsas persistentes

Supón que el formulario independiente de cuenta rechaza la ausencia de token, pero siguen apareciendo cuentas basura. Rastrea una creación de muestra hasta su ruta real. Un proceso de compra personalizado puede enviar datos de invitado o cuenta por otro punto de acceso, mientras un importador o integración puede crear clientes sin usar el formulario público de registro. Confirma el comportamiento previsto de esa ruta en lugar de subir el umbral de puntuación de otro formulario.

Para el spam de contacto, distingue igualmente entre un mensaje creado mediante el formulario de la tienda y spam enviado directamente a tu buzón. Un desafío de formulario no puede interceptar correo directo. Una vez identificada la ruta, repite allí un envío válido y una prueba de rechazo, comprobando el cliente, mensaje o cola de correo resultantes.

Prueba los rechazos, las caídas y los clientes legítimos

Ejecuta la siguiente matriz en un entorno de pruebas para cada formulario previsto y cada ruta compatible. Usa cuentas de prueba y receptores de correo de prueba y verifica tanto los efectos como la respuesta visible.

Prueba con teclado, lector de pantalla, conexión móvil y herramientas de privacidad. Conserva los datos introducidos cuando sea seguro y ofrece una vía de contacto útil, como el soporte de mypresta.rocks para problemas con sus módulos.

Ajusta la puntuación según tu propia distribución de puntuaciones por acción, el abuso y las tasas de finalización legítima. Un umbral como 0,5 es un valor de prueba, no un ajuste seguro universal. No des por hecho que un navegador, VPN o velocidad de escritura concretos explican una puntuación baja.

Mide las solicitudes al proveedor y los recursos transferidos en un navegador antes de elegir las reglas de carga. La carga global puede añadir trabajo a páginas sin formularios protegidos; la carga condicional debe seguir cubriendo formularios de pie de página, ventanas modales y formularios insertados por AJAX. No existe un volumen fijo de JavaScript ni una mejora de conversión aplicable a todas las configuraciones.

Supervisa los formularios enviados, rechazos del servidor, falsos positivos, resultados de spam y finalizaciones de pedidos durante periodos comparables. Separa visualizaciones, intentos, envíos aceptados y resultados no deseados cuando tus informes lo permitan y anota las campañas u otros cambios en la composición de clientes. Una bajada o subida del spam no demuestra por sí sola que la integración sea correcta. Si las comprobaciones del proveedor se superan pero los mensajes aceptados siguen siendo no deseados, revisa el contenido y el patrón de envío; un desafío verificado no garantiza una consulta útil.

Aplica restricciones de acceso y plazos de conservación proporcionados

Una restricción por IP se dirige a una dirección de red, no a una persona. Oficinas, universidades, redes de operadores, VPN y proxies pueden atender a clientes sin relación entre sí. Un visitante abusivo puede cambiar de dirección. Los metadatos del navegador no son una identificación única ni una prueba de que varias cuentas pertenezcan a una persona.

Usa la acción, la caducidad y el rango de direcciones más acotados que resulten adecuados. Una dirección exacta es más limitada que 203.0.113.0/24; un comodín o un intervalo arbitrario de direcciones puede afectar a muchos visitantes. Comprueba la compatibilidad IPv6 de la integración antes de suponer que se aplican sus reglas de coincidencia IPv4.

Una restricción de compra puede incluir rutas de carrito, mientras que una restricción de autenticación puede cubrir páginas de cuenta, identidad y contraseña. Las rutas de compra y pago personalizadas pueden comportarse de otra forma. Prueba de principio a fin con usuarios bloqueados y permitidos y conserva un acceso operativo revisado para tu equipo y la monitorización.

Confirma el módulo de visitantes y el esquema instalados antes de consultar tablas mprvc_*. Para metadatos y ajustes específicos de restricciones, campos y caducidad, utiliza la página de ayuda de Customer Extra Info (IP Ban); la caducidad del bloqueo desactiva la restricción y no borra por sí sola el registro.

Documenta la finalidad, el motivo, el revisor y el periodo de conservación. Recopila solo lo que necesites y distingue los campos opcionales de los datos que la integración registra siempre. Elimina la información obsoleta mediante un proceso deliberado de conservación, manteniendo las pruebas de incidentes cuando sea necesario.

Que un país quede fuera de tu zona de entrega no justifica automáticamente denegar el acceso al sitio. Las normas de la UE limitan las restricciones y redirecciones basadas en nacionalidad y residencia; aplica medidas de seguridad legales y proporcionadas y revisa los pedidos existentes y las obligaciones contractuales. Consulta el Reglamento (UE) 2018/302.

Ejemplo práctico: una oficina comparte la dirección que quieres bloquear

Si los registros falsos repetidos proceden de una dirección que también utiliza un cliente empresarial legítimo, compara las horas de creación y las rutas de solicitudes antes de actuar. Prefiere una regla sobre la acción de registro abusada a una restricción de toda la tienda cuando la integración lo permita. Comprueba qué cubre realmente una regla de autenticación: también puede impedir el acceso o la recuperación de contraseña de ese cliente. Prueba el recorrido de un compañero autorizado además de la solicitud no deseada, fija una revisión e indica al soporte cómo comunicar un rechazo erróneo.

El acceso en mantenimiento es otro control

La lista de IP permitidas en Parámetros de la tienda > Configuración > Mantenimiento permite a los visitantes incluidos acceder a una tienda en mantenimiento. No es una lista de bloqueo para expulsar a un infractor de una tienda abierta. Utiliza el control cuyo ámbito corresponda a la acción que quieras restringir.

Consentimiento y privacidad del proveedor

La CNIL distingue las operaciones de CAPTCHA dedicadas solo a seguridad de las que también sirven para otras finalidades que requieren consentimiento. Cuando se requiere consentimiento, rechazarlo no debe permitir saltarse la seguridad: ofrece un control alternativo o complementario que no necesite ese consentimiento. Cambiar de proveedor por sí solo no resuelve las obligaciones de protección de datos y transferencias internacionales. Sigue la guía de la CNIL sobre CAPTCHA, pregunta 17.

Un hook llamado displayGDPRConsent puede ser un punto de colocación de un widget. Su nombre no establece un bloqueo basado en consentimiento. Comprueba las solicitudes de scripts antes del consentimiento, tras rechazarlo y tras retirarlo, y prueba también la vía del servidor.

Gestiona los carritos vacíos y revisa el resultado

Un GET de categoría no guarda automáticamente un carrito por cada visitante. El procesamiento nativo de añadir al carrito comprueba primero los productos y las cantidades. Un procesamiento válido de añadir al carrito, un módulo u otro flujo de sesión pueden crear un carrito; un fallo posterior puede dejarlo vacío. Los carritos anónimos o vacíos por sí solos no demuestran actividad de bots ni ventas perdidas.

Correlaciona las horas de creación de carritos con las solicitudes e identifica el componente que los guarda. Los controles de tráfico pueden reducir las solicitudes que interceptan, pero no garantizan que se detenga el aumento de carritos ni eliminan los registros existentes.

Usa copias de seguridad y una limpieza limitada por antigüedad que tenga en cuenta las dependencias. Conserva los carritos vinculados a pedidos, las cestas legítimas recuperables, las personalizaciones, los archivos asociados y los registros de incidentes necesarios. Ocultar ruido confirmado de las vistas operativas es distinto de eliminarlo.

Revisa los límites tras cambiar URL, temas, módulos de pago o tráfico. Confirma que siguen funcionando los rastreadores conocidos, la monitorización, las llamadas de retorno de pagos, los clientes en redes compartidas y las herramientas de accesibilidad. Observa conjuntamente las solicitudes rechazadas, los falsos positivos, los tiempos de respuesta y la capacidad de generación de páginas.

Las cifras históricas de rastreadores son contexto, no una previsión de capacidad. Cloudflare midió un crecimiento agregado del 18% de rastreadores de búsqueda e IA entre mayo de 2024 y mayo de 2025, con un pico en abril de 2025 un 32% superior al de mayo de 2024. En su desglose, las solicitudes de Googlebot aumentaron un 96% y su cuota pasó de alrededor del 30% al 50%; las solicitudes de GPTBot aumentaron un 305%, del 2,2% al 7,7% de cuota. ClaudeBot cayó un 46% y Bytespider un 85%; la cuota de PerplexityBot pasó de menos del 0,01% al 0,2%. La serie agregada no subió de forma continua. Consulta el análisis fechado de rastreadores de Cloudflare. Dimensiona los controles según tu propio tráfico actual.

Combina este trabajo con actualizaciones, autenticación sólida del back office y monitorización. Usa la guía de seguridad para la lista de comprobación más amplia y la guía de respuesta a brechas de seguridad si sospechas una intrusión.

Aplica un cambio reversible y traspasa su gestión

1. Registra la situación inicial. Guarda las rutas afectadas, los ajustes actuales y las pruebas del problema. Acuerda cómo debería manifestarse la mejora y qué fallos de clientes o integraciones requieren revertir.
2. Cambia un ámbito definido. Ensaya las pruebas pertinentes en el entorno de pruebas y conserva la configuración anterior. Evita cambiar a la vez la regla perimetral, el umbral de CAPTCHA y las restricciones de visitantes, lo que dificulta atribuir un rechazo.
3. Comprueba las diferencias de producción. Confirma los hosts reales, las claves del proveedor, la confianza en proxies, las restricciones del origen y las funciones disponibles del plan perimetral antes del cambio previsto.
4. Realiza la prueba acotada en producción. Utiliza recorridos de cliente controlados y comprobaciones de llamadas de retorno compatibles con el proveedor. Inspecciona la respuesta y el efecto reales; una página de inicio que funciona no demuestra que sigan funcionando el pago, el acceso o los webhooks.
5. Revisa ambos resultados. Compara el trabajo restante del origen y los envíos no deseados con las finalizaciones legítimas y los informes del soporte. Si falla un recorrido válido, revierte el cambio responsable e investiga la solicitud registrada.
6. Deja un registro operativo. Guarda el ámbito final, excepciones, revisor, fecha de revisión e instrucciones de reversión. Asegúrate de que otra persona autorizada puede acceder al panel de control si el administrador habitual está bloqueado o ausente.

Qué preguntar a tu desarrollador o agencia

• ¿Qué componente recibe cada solicitud afectada y qué pruebas la vinculan con el problema?
• ¿Dónde se confía en la dirección original del cliente y puede una cabecera entrante cambiar la dirección registrada o bloqueada?
• ¿Qué rutas y efectos se probaron con nuestras versiones instaladas de tema, proceso de compra y módulos, incluidos envíos directos y fallos del proveedor?
• ¿Qué clientes automatizados y clientes en redes compartidas se comprobaron y qué carga queda fuera de la regla?
• ¿Quién puede revertir el cambio, dónde están los resultados sin datos sensibles y qué futuros cambios de rutas o integraciones requieren otra prueba?

Preguntas habituales de los propietarios

Mi alojamiento recomienda un servidor mayor. ¿Debo aceptar?

Pide pruebas del cuello de botella y de las solicitudes que lo causan. Una mayor capacidad puede estar justificada por demanda legítima, pero compara la carga restante tras una prueba de tráfico acotada. Un servidor mayor por sí solo mantiene disponibles las rutas no deseadas.

¿Por qué un cliente solo tiene problemas en el teléfono?

Pide la hora, la página afectada y el error visible sin recoger contraseñas ni tokens. Rastrea ese intento por el servicio perimetral, el servidor y la integración del formulario y reproduce después el recorrido con el navegador y la conexión móvil pertinentes. Cambiar todos los ajustes de protección antes de identificar la capa que rechaza puede ocultar la causa.

¿Podemos probar la protección inundando de solicitudes el pago en producción?

Utiliza un plan de pruebas acordado y limitado en un entorno aislado. Confirma quién controla la prueba, qué límites la detienen y cómo se mantienen aislados los pedidos, correos y pagos. La validación en producción debe utilizar los recorridos controlados acordados con tu alojamiento y los proveedores de integraciones.

¿Superar un CAPTCHA significa que es seguro atender un pedido?

No. Verifica el desafío de formulario configurado, no la titularidad de una cuenta, la legitimidad del pago ni el riesgo de entrega. Mantén la revisión de pedidos y pagos necesaria para tu negocio antes de enviar la mercancía.