Per què les API són especialment vulnerables?
Les interfícies de programació connecten sistemes interns i externs, gestionen dades sensibles i funcionen de manera automatitzada — sense validació humana a cada crida. Les proteccions tradicionals de perímetre de xarxa no són suficients quan cada client autoritzat pot realitzar milers de consultes per minut. L'OWASP API Security Top 10 documenta classes recurrents de vulnerabilitats, moltes de les quals no resulten d'errors en el codi, sinó d'un disseny de seguretat insuficient a nivell d'arquitectura.
Autenticació i autorització — el fonament
OAuth2 amb el flux Authorization Code i PKCE constitueix l'estàndard d'or per a APIs accessibles des d'aplicacions client. Per a la comunicació servidor-servidor, el flux Client Credentials amb tokens d'accés de curta durada és l'adequat. Els errors clau que s'han d'eliminar en la fase de disseny són: emmagatzematge de tokens a localStorage en lloc de memòria volàtil, manca de validació de l'àmbit de permisos a cada crida, omissió de la verificació del camp audience al token JWT i ús de claus API estàtiques sense mecanisme de rotació.
- Tokens d'accés: temps de vida màxim de 15-60 minuts
- Tokens d'actualització: emmagatzemats en cookies segures httpOnly o en un magatzem segur del servidor
- Rotació de claus API: obligatòria, automatitzada, sense temps d'inactivitat
- Inspecció de cada crida quant a l'àmbit de permisos — no només en el moment d'iniciar sessió
Rate limiting com a protecció contra abusos
La limitació del nombre de crides per unitat de temps protegeix les API contra diverses classes d'amenaces simultàniament: atacs de força bruta sobre credencials, raspat de dades, atacs DDoS dirigits a la lògica de negoci i sobrecàrrega accidental per clients amb errors. Una implementació eficac del rate limiting requereix granularitat — límits diferents per a consultes no autenticades, per a usuaris autenticats i per a socis amb confiança elevada. Els límits s'han d'aplicar a nivell d'adreça IP, identificador d'usuari i clau API conjuntament.
Cal prestar atenció a la codificació adequada d'errors — el codi 429 Too Many Requests ha d'incloure la capçalera Retry-After, cosa que permet el comportament correcte dels clients i redueix el nombre de reintents. Els límits excessivament restrictius generen frustració als usuaris i dificulten el diagnòstic de problemes.
WAF i inspecció del trànsit API
El Web Application Firewall de nova generació entén l'estructura de les API — verifica la correcció del JSON, detecta intents d'injecció en els valors dels camps, bloqueja patrons d'exploits coneguts i monitoritza anomalies en les mides de les càrregues i la freqüència de crides. La configuració del WAF per a API requereix un enfocament diferent del de les aplicacions web tradicionals — les regles han de considerar l'especificitat de cada endpoint, els tipus i mides de dades permesos i els patrons d'ús esperats.
Monitoratge i detecció d'anomalies
Fins i tot les API millor configurades requereixen monitoratge continu. Els sistemes de detecció d'anomalies aprenen els patrons d'ús normals — hores del dia, seqüències típiques de crides, distribució d'adreces IP — i alerten sobre desviacions. Especialment valuosos són el monitoratge de crides amb errors 401 i 403 (intents d'accés no autoritzat), mides de resposta inusuals (potencial filtració de dades) i seqüències que suggereixen enumeració de recursos.
ESKOM.AI dissenya la seguretat de les API com un element integrat de l'arquitectura, no una capa afegida a posteriori. Cada API explorada pel sistema d'automatització passa una avaluació de vulnerabilitats conforme a l'OWASP API Top 10 abans d'entrar en producció.