Per què les APIs són un objectiu tan atractiu
Cada vegada que una app mòbil consulta dades, o que dos serveis es comuniquen, hi ha una API darrere. Les APIs exposen directament la lògica de negoci i les dades, de vegades sense les mateixes proteccions que tenen les interfícies web.
OWASP publica el seu API Security Top 10 per documentar els riscos més comuns. Veiem els principals.
API1: Broken Object Level Authorization (BOLA)
El més freqüent i el més explotat. Passa quan una API no verifica si l'usuari autenticat té permís per accedir a l'objecte que sol·licita.
Exemple: GET /api/factures/1234 retorna la factura 1234 sense comprovar si pertany a l'usuari que fa la petició. Canvia l'ID i veus factures d'altres usuaris.
Sempre valida autorització a nivell d'objecte, no només a nivell d'endpoint.
API2: Broken Authentication
Tokens sense expiració, JWT amb algoritme "none", contrasenyes en paràmetres GET, manca de rate limiting en login... Els mecanismes d'autenticació mal implementats són una porta d'entrada clàssica.
- Usa tokens amb expiració curta + refresh tokens
- Mai facis servir JWT amb algoritme
none - Rate limiting obligatori a tots els endpoints d'autenticació
API3: Broken Object Property Level Authorization
Similar a BOLA però a nivell de propietats. L'API retorna (o accepta modificar) camps sensibles que l'usuari no hauria de veure o editar. Un exemple típic: un endpoint de perfil que retorna el camp is_admin: false. Canviar aquest camp en una petició PATCH i fer-se admin és "mass assignment".
API4: Unrestricted Resource Consumption
Sense límits a les peticions, mida del payload, nombre de resultats o temps de processament, qualsevol endpoint pot convertir-se en un vector de DoS. Sempre defineix:
- Paginació amb límit màxim de resultats
- Rate limiting per usuari/IP
- Mida màxima del request body
- Timeouts en operacions costoses
API5: Broken Function Level Authorization
Endpoints administratius accessibles per a usuaris normals. De vegades estan "ocults" però no protegits: /api/admin/users retorna tots els usuaris a qualsevol que conegui la ruta.
API6: Unrestricted Access to Sensitive Business Flows
Nou a la versió 2023. Automatitzar fluxos de negoci que no estaven pensats per ser automatitzats: comprar tot l'estoc disponible d'un producte amb bots, crear milers de comptes per obtenir bons de registre, etc.
API7: Server-Side Request Forgery (SSRF)
L'API accepta una URL com a input i fa una petició a aquesta URL al servidor. Un atacant pot apuntar a http://169.254.169.254 (metadata de cloud) o a serveis interns no exposats públicament.
API8: Security Misconfiguration
Headers de seguretat absents, CORS permissiu (*), stack traces en producció, endpoints de debug actius, versions amb CVEs coneguts... La configuració insegura és potser la més fàcil de prevenir amb una revisió sistemàtica.
API9: Improper Inventory Management
APIs desactualitzades, versions antigues sense suport, endpoints no documentats que continuen actius. /api/v1/ deprecada però encara funcionant i sense els pedaços de seguretat de /api/v3/.
API10: Unsafe Consumption of APIs
Confiar cegament en APIs de tercers. Si una API externa que consumeixes retorna dades malicioses (injecció SQL, XSS, path traversal), el teu servei les propagarà si no les valides.
Per on començar
Si estàs començant amb seguretat en APIs, la meva recomanació és:
- Llegir la documentació oficial d'OWASP API Security
- Practicar amb crAPI (Completely Ridiculous API) — aplicació vulnerable dissenyada per aprendre
- Revisar les teves pròpies APIs amb OWASP ZAP o Burp Suite Community