Por que as API son especialmente vulnerables?
As interfaces de programación conectan sistemas internos e externos, xestionan datos sensibles e funcionan de forma automatizada — sen validación humana en cada chamada. As proteccións tradicionais de perímetro de rede non son suficientes cando cada cliente autorizado pode realizar miles de consultas por minuto. O OWASP API Security Top 10 documenta clases recorrentes de vulnerabilidades, moitas das cales non resultan de erros no código, senón dun deseño de seguridade insuficiente a nivel de arquitectura.
Autenticación e autorización — o fundamento
OAuth2 co fluxo Authorization Code e PKCE constitúe o estándar de ouro para APIs accesibles desde aplicacións cliente. Para a comunicación servidor-servidor, o fluxo Client Credentials con tokens de acceso de curta duración é o axeitado. Os erros clave que se deben eliminar na fase de deseño son: almacenamento de tokens en localStorage en lugar de memoria volátil, falta de validación do ámbito de permisos en cada chamada, omisión da verificación do campo audience no token JWT e uso de chaves API estáticas sen mecanismo de rotación.
- Tokens de acceso: tempo de vida máximo de 15-60 minutos
- Tokens de actualización: almacenados en cookies seguras httpOnly ou nun almacén seguro do servidor
- Rotación de chaves API: obrigatoria, automatizada, sen tempos de inactividade
- Inspeeción de cada chamada canto ao ámbito de permisos — non só no momento de iniciar sesión
Rate limiting como protección contra abusos
A limitación do número de chamadas por unidade de tempo protexe as API contra varias clases de ameazas simultaneamente: ataques de forza bruta sobre credenciais, raspado de datos, ataques DDoS dirixidos á lóxica de negocio e sobrecarga accidental por clientes con erros. Unha implantación eficaz do rate limiting require granularidade — límites diferentes para consultas non autenticadas, para usuarios autenticados e para socios con confianza elevada. Os límites deben aplicarse a nivel de enderezo IP, identificador de usuario e chave API conxuntamente.
Hai que prestar atención á codificación axeitada de erros — o código 429 Too Many Requests debe incluír a cabeceira Retry-After, o que permite o comportamento correcto dos clientes e reduce o número de reintentos. Os límites excesivamente restritivos xeran frustración nos usuarios e dificultan o diagnóstico de problemas.
WAF e inspeeción do tráfico API
O Web Application Firewall de nova xeración entende a estrutura das API — verifica a corrección do JSON, detecta intentos de inxección nos valores dos campos, bloquea patróns de exploits coñecidos e monitoriza anomalías nos tamaños das cargas e a frecuencia de chamadas. A configuración do WAF para API require un enfoque diferente do das aplicacións web tradicionais — as regras deben considerar a especificidade de cada endpoint, os tipos e tamaños de datos permitidos e os patróns de uso esperados.
Monitorización e detección de anomalías
Mesmo as API mellor configuradas requiren monitorización continua. Os sistemas de detección de anomalías aprenden os patróns de uso normais — horas do día, secuencias típicas de chamadas, distribución de enderezos IP — e alertan sobre desvios. Especialmente valiosas son a monitorización de chamadas con erros 401 e 403 (intentos de acceso non autorizado), tamaños de resposta inusuais (potencial filtración de datos) e secuencias que suxiren enumeración de recursos.
ESKOM.AI deseña a seguridade das API como un elemento integrado da arquitectura, non unha capa engadida a posteriori. Cada API explorada polo sistema de automatización pasa unha avaliación de vulnerabilidades conforme ao OWASP API Top 10 antes de entrar en produción.