Rate limiting
El rate limiting aplica en dos capas independientes — el proxy inverso protege contra tráfico genérico antes de que llegue al backend, y el backend aplica límites más finos por política y por identidad (usuario, IP o API key) según el endpoint.
Capa 1: proxy inverso (todo el tráfico)
Ver el detalle completo en Hardening — hasta 10 requests/segundo
sostenidas por IP, ráfagas de hasta 20, 429 a partir de ahí. Aplica a todo el tráfico HTTP
antes de llegar a cualquier backend, no solo al de ABA.
Capa 2: políticas del backend
Cada política tiene su propia estrategia y su propia clave de identidad — no todos los límites se cuentan por IP, algunos se cuentan por usuario autenticado o por célula (vía API key), lo que importa para no penalizar a un usuario legítimo por el tráfico de otro que comparte su misma IP (por ejemplo, dos estudiantes en la misma red universitaria).
| Política | Estrategia | Límite | Aplica a |
|---|---|---|---|
global | Ventana fija (IP) + concurrencia | 60 req/min | Todo request, límite por defecto |
sliding | Ventana deslizante | 10 req/min | Lecturas del dashboard |
landing | Ventana deslizante (IP) | 20 req/min | GET /stats — única superficie pública sin autenticar |
auth | Ventana fija (IP) | 5 / 5 min | Callbacks de OAuth |
provisioning | Token bucket (usuario) | ráfaga 1, recarga 1 / 10 min | Crear una base de datos nueva |
credenciales | Ventana fija (usuario) | 5 / hora | Revelar credenciales de una base ya creada |
partners | Token bucket (por célula, vía API key) | ráfaga 5, recarga 1 / 2 min | API de aprovisionamiento para células socias |
Por qué provisioning es tan estricto
Crear una base de datos es la operación más costosa del sistema — involucra dos motores de base de datos y deja un recurso real (una base MySQL con su propio usuario) provisionado. Un límite de "una cada 10 minutos" no es arbitrario: existe específicamente para que un bug de frontend o un doble clic no termine generando decenas de bases huérfanas para el mismo usuario.
Kestrel como última línea de defensa
Aunque el backend nunca debería recibir tráfico directo de internet (Nginx siempre está delante), el servidor Kestrel del propio proceso .NET también está endurecido directamente (límites de conexiones concurrentes, timeouts de headers, tasa mínima de datos del body) — una capa adicional contra ataques de tipo Slowloris, por si alguna vez algo bypasea el proxy inverso.