fix(security): endurecimiento de seguridad mediante limitación de tasa en autenticación y alertas

[Ochoa-Stack]

fix/security-hardening-round-one

Descripción

En este ciclo, elevamos la postura de seguridad de la plataforma implementando controles de limitación de tráfico (rate limiting) y cuotas operativas sobre rutas críticas. Estas medidas previenen ataques de fuerza bruta, saturación de envío de correos y el agotamiento deliberado de los recursos del motor de notificaciones.

Detalles técnicos que integramos:

• Limitación en Autenticación (fix): Intervenimos auth_bp.py inyectando restricciones de frecuencia sobre el flujo de restablecimiento de contraseña (reset-password). Esto mitiga vectores de ataque orientados a la enumeración invasiva o al bombardeo de correos electrónicos (email spam/bombing).
• Cuotas de Creación de Alertas (fix): Modificamos alerts_bp.py para establecer un límite estricto en la creación de alertas por usuario. Esta barrera protege la infraestructura contra la saturación del orquestador de ingesta y evaluación.
• Cobertura de Integración (test): Actualizamos el módulo de pruebas test_alerts_endpoints.py para certificar empíricamente el rechazo de peticiones (típicamente mediante el código de estado 429 Too Many Requests o 403 según el diseño de cuota) una vez que un cliente excede el umbral seguro.

Tipo de cambio

• feat
• fix
• refactor
• chore
• docs
• test
• ci

Cómo probar

1. Tras el merge, sincronizamos la rama base en nuestro entorno local.
2. En la raíz del backend (cd backend), activamos el entorno virtual.
3. Ejecutamos la validación automatizada para confirmar la integridad de los nuevos límites de seguridad:
   pytest tests/integration/test_alerts_endpoints.py -v
4. Levantamos el servidor de desarrollo local (flask run).
5. Prueba de Autenticación: Mediante un cliente HTTP (ej. Thunder Client, Postman o curl), enviamos múltiples peticiones consecutivas al endpoint de reset-password. Confirmamos que, tras superar el umbral definido, la API comienza a rechazar las solicitudes para ese identificador/IP.
6. Prueba de Cuotas: Con un usuario autenticado, ejecutamos peticiones de creación de alerta hasta alcanzar el límite máximo permitido por cuenta. Confirmamos que la API aborta las creaciones adicionales.

Checklist

• Sigue las convenciones de commits del proyecto (separación atómica)
• Los flujos de recuperación de credenciales están protegidos contra abuso de tráfico
• El motor de alertas cuenta con cuotas de creación para prevenir agotamiento de recursos
• La suite de pruebas verifica los rechazos tras el incumplimiento de los límites operativos