Si gestionas una web en la que se venden entradas, se lanzan productos con existencias limitadas o se gestionan ventas de gran demanda, ya sabes lo que ocurre cuando hay demasiada gente al mismo tiempo.
La web se cuelga, los clientes reales se encuentran con páginas de error y los bots se llevan discretamente todo lo que está en oferta.
Una sala de espera virtual es la solución habitual: cuando la demanda se dispara, CrowdHandler mantiene a los visitantes en una cola ordenada y los va admitiendo a un ritmo que tu infraestructura pueda realmente soportar, de modo que la web se mantenga operativa y todos tengan las mismas oportunidades.
Eso funciona bien cuando la sala de espera se encuentra al principio de todo el sitio web. El problema es que las aplicaciones modernas cada vez se diseñan menos de esa forma, y muchas de ellas están protegidas de una manera que parece sólida, pero no lo es.
La varita que nunca
Ya sabes cómo es el cacheo de seguridad. El portero te da unas palmaditas, os miráis y pasas. En realidad, no te han registrado nada. Así es como funcionan la mayoría de las aplicaciones web: mucho movimiento, pero sin contacto real.
¿Por qué todo el mundo construye así?
Así pues, la pila moderna se divide claramente en dos.
- Hay una interfaz de usuario, que suele ser estática o generada por el servidor.
- Hay una API que está un poco apartada, a menudo en su propio dominio y, a veces, en una nube totalmente independiente.
Ahora es la configuración predeterminada. Next.js, Nuxt, Remix, SvelteKit y Astro lo recomiendan. Las plataformas de comercio «headless» te lo ofrecen ya dividido: una tienda alojada por un lado y una API pública por el otro, dejando que el usuario se encargue de la integración.
Aloja el front-end en Vercel, Netlify o Cloudflare Pages, y tendrás el modelo que adoptan casi todas las plataformas de comercio electrónico y venta de entradas en 2026: un front-end rápido y mayoritariamente estático, y una API que se encarga de todo el trabajo real en otro lugar.
Es ideal para la experiencia del desarrollador. Es ideal para la velocidad de la página. Sin embargo, es ahí donde falla el modelo de seguridad.
¿Por qué el front-end es una
El front-end es ultraligero. Se compone de código de marcado, scripts y un poco de estilo, y podrías lanzarle la mitad de Internet sin que se inmutara, porque no hay casi nada ahí que pueda saturarlo.
Todas las operaciones costosas, frágiles y «peligrosas» se ejecutan en la API. Así que, si tu «sala de espera» se basa en el sitio web estático, mientras que tu API responde a llamadas entre dominios desde su propia dirección, has protegido la parte que nunca iba a fallar y has dejado totalmente expuesta la parte que sí falla.
Los clientes entran por la entrada vigilada. Los problemas se cuelan por una puerta lateral que nadie vigila.
Nos encontramos con esto constantemente: aplicaciones SPA y aplicaciones de tipo SPA creadas exactamente de esta manera. Sinceramente, mucha gente preferiría no saberlo y, mientras nada falle, tiene su lógica no indagar más.
Los equipos que prefieren verlo con claridad quieren una sala de espera que abarque ambas mitades, no un escudo que proteja solo a la más inofensiva.
Tenemos dos métodos que han demostrado su eficacia para hacerlo.
Estrategia 1: utilizar tu principal como proxy para la API
La mejor opción, si te lo puedes permitir, es dejar de tratar la API como una dirección independiente. Redirige sus llamadas a través de tu dominio principal y coloca un escudo que las proteja a todas, ya sea CrowdHandler, Cloudflare o cualquier otra solución que ya tengas en uso.
Si lo haces así, el front-end ligero acabará representando a todo el sistema. Un intento de DDoS obtiene una posición en la cola. Una llamada a la API que se salta la ruta normal obtiene una posición en la cola. El atacante espera en la cola detrás de tus clientes reales, igual que cualquier otro. Si tu arquitectura te permite adaptarte de esta forma, opta por esta solución en primer lugar.
Estrategia 2: situar a los trabajadores de perímetro frente a los puntos finales críticos
Cuando no se dobla, hay que recurrir a medidas drásticas. Los trabajadores de la línea de corte se colocaron delante de la API en los uno o dos puntos que soportan el peso.
En una tienda, casi siempre se trata de la opción «Añadir al carrito», y merece la pena explicar el motivo. Sin ella, es imposible pasar por caja, por lo que es el filtro obvio. Sin embargo, también es peligrosa en sí misma, ya que alguien que solo puede añadir productos al carrito puede arruinar la experiencia de los compradores auténticos sin llegar a comprar ni un solo artículo.
Esa es la táctica clásica de los bots de entradas: llenar los carritos con existencias para que los compradores reales no puedan acceder a ellas, para luego revender el acceso, o bien liberarlas y volver a comprarlas una y otra vez.
El trabajador gestiona esto consultando la API de CrowdHandler y contabilizando las visitas según el ID del producto, tratándolas como si hubieran llegado a la página que normalmente activa la llamada, que suele ser la página de detalles del producto. ¿No te has puesto en la cola de forma legítima para esa página? En ese caso, la llamada a la API no se realiza en tu caso.
Hay una ventaja poco conocida al instalar el «worker» justo ahí. Se sitúa directamente en el verdadero cuello de botella —la API, en lugar del sitio web estático—, lo que significa que nuestro sistema de ajuste automático puede detectar el punto que realmente se satura y permitir el paso de los usuarios a un ritmo que refleja la realidad.
Si te fijas solo en el sitio web del host, te encontrarás ante un componente que, en esencia, nunca se esfuerza, lo que equivale a realizar ajustes a ciegas. Además, dado que ese sitio web del host hace tan poco, su parte de la integración sigue siendo trivial: un poco de JavaScript para apartar a los usuarios cuando sea necesario, mientras que toda la validación y el control del ritmo reales tienen lugar en la API.
La trampa solo funciona si todas las piezas
Hay una regla que no puedes saltarte, y es precisamente la que la gente suele pasar por alto: cierra la sesión en cuanto alguien se desconecte.
Una vez que un visitante ha pagado, esa sesión debe cerrarse, de modo que no pueda reactivarse para una segunda ronda. Si se deja abierta, un bot capaz se pone en la cola exactamente una vez y, a continuación, realiza la transacción en bucle de forma indefinida. Si se aplica esta medida, se elimina esa opción, lo que obliga al atacante a comportarse como un comprador normal en el «happy path» en cada ocasión: pasando por la cola, por la página del producto y por la llamada validada.
La trampa solo atrapa algo si todas las piezas encajan. Basta con que haya un componente suelto para que todo se cierre de golpe sin atrapar nada.
No hace falta que reescribas tu
Para que quede claro cuál es el alcance, no se trata de una reconstrucción. Se trata principalmente de cargar y ajustar los «edge workers» que ya creamos y mantenemos, con versiones preparadas para:
- AWS CloudFront
- Cloudflare
- Netlify
- Akamai
Estás protegiendo uno o dos puntos finales, sin tocar tu código principal. Lo hemos hecho discretamente para una larga lista de clientes en una amplia variedad de plataformas, y es el mismo mecanismo el que funciona en segundo plano en nuestra integración con Shopify.
Cuando esto merezca una
Si hay algo en el fondo de tu mente que no deja de decirte que tu configuración está un poco más expuesta de lo que admitirías en voz alta, habla con nosotros. Aunque una cola tradicional te parezca excesiva, así es como consigues una limitación de tasa elegante y protección contra ataques DDoS integradas en aquellas partes de tu aplicación que realmente ceden, y no en las que ni siquiera se inmutan.
¿Necesitas un poco más de seguridad? Regístrate gratis en CrowdHandler.