Casos de uso

Proteger una aplicación existente sin tocarla

Necesidad: una aplicación en producción, en tu centro de datos o en un servidor alquilado, a la que querés sumar certificado, WAF, límites y análisis de tráfico sin cambiar su código ni mudarla.

Combinación:

Proxy inverso hacia el servidor donde ya corre.
TLS automático.
WAF con la base y las reglas incorporadas activas desde el primer día.
Limitación de tasa en las rutas de autenticación.
Análisis de tráfico para ver visitas reales, bots y bloqueos.

Sitio bajo ataque sostenido de bots

Necesidad: una API pública recibe extracción masiva de contenido y ataques de relleno de credenciales.

Combinación:

WAF con reglas propias contra los agentes de usuario identificados. El bloqueo automático de escáneres frena a quien recorre la API buscando vulnerabilidades.
Limitación de tasa estricta en /auth (por ejemplo, 5 solicitudes por minuto por dirección IP).
Reputación de IP con CrowdSec.
Geo-bloqueo de los países desde donde llega el ataque y donde no operás.
El informe de seguridad del análisis de tráfico para ver qué IPs, desde qué países y con qué reglas se bloquearon, y ajustar.

Servicios internos con acceso por certificado

Necesidad: publicar herramientas internas (un panel, una intranet) accesibles solo desde los equipos de la organización.

Combinación:

Certificados privados para los dominios internos, con la raíz instalada en los equipos.
Autenticación mutua obligatoria: sin un certificado de cliente emitido para el equipo, no hay acceso. Un equipo perdido se revoca en el momento.
La identidad del certificado llega a la aplicación en un encabezado, para registrar quién hizo qué.

Sitio estático con formulario, sin servidores

Necesidad: una landing o un sitio institucional con un formulario de contacto, sin mantener ningún servidor.

Combinación:

Un dominio combinado: el sitio estático en / y una función en /api/contacto, en el mismo dominio y sin CORS.
Validación de formularios sobre /api/contacto, para que la función reciba solo datos bien formados.
Limitación de tasa en /api/contacto.
Si la función tiene que avisar a otros sistemas, un evento con entrega garantizada.

Aplicación de una sola página y API en el mismo dominio

Necesidad: app.miempresa.com sirve una aplicación de una sola página en / y una API en /api/*, que corre en tu propio servidor.

Combinación:

Un dominio combinado: una sub-ruta estática en / con fallback de aplicación de una sola página, y una sub-ruta proxy en /api hacia tu servidor.
Limitación de tasa solo en la sub-ruta de la API.
Reglas de borde para agregar Content-Security-Policy a la aplicación.

API que valida la entrada antes de procesarla

Necesidad: una API recibe formularios y JSON de varios frontends, y querés rechazar los datos mal formados (email inválido, campos faltantes, valores fuera de rango) sin repetir las mismas comprobaciones en cada servicio.

Combinación:

Validación de formularios con esquemas estilo Zod sobre /api/**, que responde 422 con el detalle de cada error.
Reutilización de los esquemas de Zod que el front ya define.
Modo “solo registro” al principio, para medir el impacto antes de activar el bloqueo.
WAF en paralelo para los ataques (el WAF responde 403; la validación, 422).

Automatizar un flujo de pedidos

Necesidad: cuando entra un pedido, cobrarlo, emitir el comprobante y avisar al cliente, en ese orden y sin perder ningún paso si algo falla.

Combinación:

El sistema de pedidos envía un evento pedido.creado al ingreso de eventos del dominio.
Funciones suscritas con entrega duradera y el identificador del pedido como clave de orden: cada paso emite el evento que dispara el siguiente, y los eventos de un mismo pedido se procesan en orden.
Los eventos que agotan sus reintentos quedan en la bandeja de fallidos para revisarlos y reintentarlos.

Lanzamiento programado de una campaña

Necesidad: una landing de campaña que se abre al público el martes a las 10:00, que el equipo tiene que poder revisar antes.

Combinación:

Mantenimiento programado hasta el martes a las 10:00, con un mensaje de “próximamente” y las IP del equipo de marketing autorizadas para revisar antes.
Geo-bloqueo de los países donde la campaña no aplica.
Adquisición para medir qué canal y qué campaña trajo cada visita, con los parámetros UTM de los anuncios.

WordPress o WooCommerce gestionado

Necesidad: uno o varios sitios WordPress con TLS automático, defensa contra bots y aislamiento respecto de otros sitios.

Combinación:

WordPress gestionado, con base de datos propia y configuración endurecida desde el alta.
Caché de contenido para /wp-content/uploads/*, *.css y *.js.
Reglas de borde que cierran /wp-admin salvo desde direcciones IP conocidas.
Limitación de tasa en /wp-login.php.