PROTECCIÓNANTI-DDOS
Varias tiendas recibían ataques de bots contra las URLs de los filtros de producto. La defensa son tres capas que distinguen al bot del cliente por cómo navega, sin servicios externos y sin tocar la base de datos.
La navegación por filtros es la página más cara de una tienda PrestaShop. Y es justo la que eligen los bots.
Cada combinación de filtros genera una consulta pesada que no se puede servir desde caché, porque las combinaciones son prácticamente infinitas. Un visitante normal pide unas pocas; un bot pide miles por minuto, y cada una cuesta lo que costaría un cliente real navegando.
Varias tiendas de clientes empezaron a recibir ese tipo de ataque contra sus URLs de facetas. El efecto era inmediato: la tienda se arrastraba o directamente dejaba de responder, y con ella la venta del día.
El patrón
Estudiando los ataques apareció el patrón que lo cambiaba todo: los bots aplicaban muchísimos filtros a la vez sobre la misma URL. Un cliente real rara vez pasa de cuatro o cinco.
Esa diferencia es la mejor señal posible, porque es barata de medir: el número de filtros está en la propia URL, así que se puede contar antes de tocar la base de datos e incluso antes de que arranque PHP. La defensa no tiene que adivinar quién está al otro lado — le basta con mirar cómo navega.
Qué construí
Capa Apache (.htaccess): corta los User-Agents imposibles y las URLs con demasiados filtros antes de que arranque PHP. Es la primera línea y su coste es prácticamente nulo, que es lo que hace falta cuando llegan miles de peticiones por minuto.
Capa PHP, enganchada al hook actionDispatcherBefore: un sistema de puntuación por señales — número de filtros, User-Agents falsos o imposibles, peticiones sin cookies ni Accept-Language, volumen por IP. Según los puntos acumulados: dejar pasar, frenar (429), lanzar un desafío JavaScript (503) o bloquear (403).
Modo asedio: contra una botnet distribuida, cada IP por separado parece inocente y el conteo por IP no la ve. En ese escenario la vigilancia pasa al volumen global de peticiones caras, no al de cada visitante.
Lista de intocables: el back office, los empleados, el carrito, el checkout, el login, la API y los bots verificados por DNS (Googlebot, Bingbot…) no se bloquean nunca. Una protección que corte una compra sale más cara que el propio ataque.
Contadores en APCu, con un respaldo de 64 ficheros fijos si no está disponible. En ningún caso se escribe en MySQL: la base de datos es justo lo que el ataque intenta saturar, así que la defensa no puede añadirle carga.
Sin servicios externos: todo se resuelve dentro del servidor de la tienda. Sin cuotas de terceros, sin enrutar el tráfico del cliente por una red ajena y sin depender de que un proveedor externo esté disponible.
Cómo está construido
- [ Plataforma ]PrestaShop 8 y 9
- [ Primera capa ]Apache · .htaccess
- [ Segunda capa ]PHP · actionDispatcherBefore
- [ Contadores ]APCu · respaldo en ficheros
Después
En el pico de ataques de agosto de 2026 el módulo bloqueó unas 50.000 peticiones maliciosas repartidas entre varias tiendas.
El criterio es el comportamiento, no la IP: el cliente que filtra cuatro o cinco veces sigue navegando igual que siempre, y la escalada 429 → 503 → 403 deja margen antes de cerrar la puerta del todo.
La defensa vive en el propio servidor: sin cuota de servicio externo, sin tráfico enrutado por terceros y sin una sola consulta añadida a la base de datos que el ataque pretendía tumbar.