La seguridad de APIs consiste en asegurar que cada endpoint autentique bien a quien llama, autorice cada objeto y cada campo que devuelve o modifica, y limite cuánto y cómo se usa. El OWASP API Security Top 10 (edición 2023) es la referencia para saber por dónde empezar: tres de sus diez riesgos son fallas de autorización, y son justamente las que un escáner automático no detecta.
Por qué las APIs son el blanco principal
Una API es la puerta por la que tu app móvil, tu web y tus aliados acceden a los datos y a la lógica del negocio. En una app moderna, la pantalla solo muestra; las decisiones de seguridad se toman en la API. Si la API confía en lo que le dice la app ("soy el usuario 15", "soy administrador"), cualquiera que intercepte el tráfico con un proxy gratuito puede cambiar esos valores. Por eso, en un pentesting de app móvil, la mayor parte de los hallazgos críticos aparece en el backend, no en el teléfono.
El OWASP API Security Top 10 2023 en una tabla
| ID | Riesgo | En una frase |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | Puedo ver o cambiar objetos de otro usuario cambiando un ID. |
| API2 | Broken Authentication | Puedo suplantar a alguien por fallas en login, tokens o recuperación de clave. |
| API3 | Broken Object Property Level Authorization | La API expone o deja modificar campos que no debería. |
| API4 | Unrestricted Resource Consumption | Sin límites, pueden agotar recursos o tu factura de SMS, correo o IA. |
| API5 | Broken Function Level Authorization | Un usuario común ejecuta funciones de administrador. |
| API6 | Unrestricted Access to Sensitive Business Flows | Bots abusan de un flujo legítimo: compras, registros, cupones. |
| API7 | Server Side Request Forgery (SSRF) | La API descarga una URL que le paso y llega a recursos internos. |
| API8 | Security Misconfiguration | CORS abierto, errores detallados, cabeceras y TLS mal configurados. |
| API9 | Improper Inventory Management | Versiones viejas, endpoints de prueba o APIs olvidadas siguen expuestas. |
| API10 | Unsafe Consumption of APIs | Confías ciegamente en lo que responde una API de terceros. |
Los riesgos de autorización: API1, API3 y API5
API1: BOLA, el más común
Ejemplo: tu app de delivery llama a GET /api/v1/orders/1043. Un atacante cambia el número a 1042 y ve el pedido, la dirección y el teléfono de otro cliente. Solución: en cada consulta, filtra por el dueño en el servidor (WHERE id = ? AND customer_id = usuario_de_la_sesión), nunca por un ID que envía el cliente; usa identificadores no secuenciales como defensa adicional, no como sustituto.
API3: autorización a nivel de propiedad
Ejemplo: GET /api/users/me devuelve el objeto completo, incluido el hash de la contraseña o un campo is_admin; o PATCH /api/users/me acepta {"role": "admin"} (asignación masiva). Solución: DTOs o esquemas de respuesta explícitos por rol y listas de campos permitidos en cada escritura.
API5: autorización a nivel de función
Ejemplo: el panel de administración llama a DELETE /api/admin/users/88 y el backend solo verifica que haya sesión, no que sea administrador. Solución: denegar por defecto y declarar el rol requerido en cada ruta, con pruebas automáticas que llamen a rutas de administrador con un usuario común.
Autenticación, consumo y flujos de negocio: API2, API4 y API6
API2: autenticación rota
Ejemplo: el endpoint de recuperación de clave acepta intentos ilimitados de un código de 4 dígitos, o la API acepta JWT firmados con alg: none. Solución: usa un proveedor de identidad probado, valida firma, emisor, audiencia y expiración de cada token, limita intentos y aplica MFA a cuentas sensibles.
API4: consumo sin límites
Ejemplo: POST /api/otp envía un SMS por llamada sin límite: un bot puede gastar cientos de dólares en una noche. Lo mismo ocurre con endpoints que llaman a un modelo de IA por cada petición. Solución: rate limiting por usuario, IP y dispositivo, paginación con máximos, límites de tamaño de carga y alertas de gasto en proveedores.
API6: flujos de negocio sensibles
Ejemplo: un bot crea miles de cuentas para usar el cupón de bienvenida, o reserva todo el inventario de una promoción. No hay un bug técnico: la API hace lo que debe, pero a una escala que daña al negocio. Solución: identificar los flujos críticos y añadir fricción proporcional: límites por cliente, verificación de dispositivo, detección de automatización y revisión de patrones anómalos.
Infraestructura, inventario e integraciones: API7 a API10
API7: SSRF
Ejemplo: la función "importar foto desde URL" acepta http://169.254.169.254/ y devuelve credenciales del servicio de metadatos de la nube. Solución: lista de dominios permitidos, bloquear rangos internos, no devolver la respuesta cruda y, en AWS, exigir IMDSv2.
API8: configuración insegura
Ejemplo: CORS que acepta cualquier origen con credenciales, trazas de error con rutas internas o un Swagger público en producción. Solución: configuración endurecida y versionada como código, errores genéricos al cliente y revisión en cada despliegue.
API9: inventario deficiente
Ejemplo: lanzaste /v2 con controles nuevos, pero /v1 sigue activa sin ellos, o existe un staging-api público con datos reales. Son las APIs sombra (que nadie documentó) y las APIs zombi (que debieron apagarse). Solución: inventario vivo de hosts, versiones y endpoints, generado desde la especificación OpenAPI y el gateway, con fecha de retiro para cada versión.
API10: consumo inseguro de APIs de terceros
Ejemplo: tu backend guarda sin validar la dirección que devuelve un proveedor logístico, o sigue redirecciones de una pasarela. Si ese tercero es comprometido, el ataque entra por ti. Solución: valida y sanea toda respuesta externa como si fuera entrada de usuario, usa TLS, timeouts y límites de tamaño. Si tu API alimenta un agente o un LLM, este riesgo se combina con los del OWASP Top 10 para LLMs.
Patrones de defensa: gateway, autorización y rate limiting
- API gateway como punto único de entrada: TLS, validación de tokens, rate limiting, tamaños máximos y registro centralizado. El gateway no reemplaza la autorización por objeto, que debe vivir en el servicio que conoce los datos.
- Autorización centralizada: una capa o librería de políticas (por ejemplo, basada en roles y atributos) que todas las rutas usan, en lugar de un
ifdistinto en cada controlador. - Esquemas estrictos: validar entrada y salida contra la especificación OpenAPI y rechazar campos no declarados.
- Tokens de vida corta con rotación de refresh tokens y revocación.
- Seguridad en el pipeline: pruebas de autorización automatizadas y escaneo de la especificación en cada merge, como explicamos en DevSecOps en CI/CD.
Si tu backend corre en Node.js, Firebase o AWS, revisa también nuestra guía de backend para apps móviles.
Cómo probar la seguridad de tu API
- Inventario: reúne la especificación OpenAPI, el tráfico real de la app y los hosts publicados; compáralos para encontrar endpoints no documentados.
- Matriz de autorización: para cada endpoint, qué rol puede hacer qué sobre qué objeto. Es la base de las pruebas de API1, API3 y API5.
- Pruebas con dos usuarios del mismo rol y de roles distintos, intercambiando IDs y tokens.
- Pruebas de límites: ráfagas de peticiones, paginación extrema y cargas grandes.
- Revisión de configuración: CORS, cabeceras, mensajes de error y versiones expuestas.
Las herramientas automáticas ayudan con API8 y parte de API9; los riesgos de autorización y de lógica de negocio requieren un pentesting manual de caja gris, que es como abordamos las APIs en nuestro servicio de ciberseguridad.
Logging y monitoreo
Registra en cada petición: usuario, endpoint, objeto accedido, resultado y origen, sin guardar contraseñas, tokens ni datos sensibles completos. Alerta sobre picos de respuestas 403 y 404 de un mismo usuario (señal típica de enumeración de IDs) y sobre consumos anómalos. Esos registros también te sirven como evidencia ante la LOPDP si ocurre un incidente.
Preguntas frecuentes
¿Qué es el OWASP API Security Top 10?
Es una lista de los diez riesgos de seguridad más críticos en APIs, publicada por la fundación OWASP. La edición vigente es la de 2023 e incluye, entre otros, autorización rota a nivel de objeto (BOLA), autenticación rota, consumo de recursos sin restricciones, SSRF, inventario deficiente y consumo inseguro de APIs de terceros. Es gratuita y sirve como base para diseñar y probar APIs.
¿Qué es BOLA en una API?
BOLA (Broken Object Level Authorization) ocurre cuando una API devuelve o modifica un objeto con solo recibir su identificador, sin verificar que pertenece al usuario que hace la petición. Por ejemplo, cambiar el número de pedido en la URL y ver el pedido de otro cliente. Se corrige validando la propiedad del objeto en el servidor en cada consulta.
¿Un API gateway es suficiente para asegurar mi API?
No. Un API gateway centraliza controles útiles como TLS, validación de tokens, rate limiting y registro, pero no sabe si el pedido 1042 pertenece al usuario que lo pide. La autorización por objeto y por campo debe implementarse en el servicio que conoce los datos, y probarse con usuarios de distintos roles.
¿Qué son las APIs sombra y las APIs zombi?
Las APIs sombra son endpoints en producción que no están documentados ni inventariados, a menudo creados para una prueba o una integración puntual. Las APIs zombi son versiones antiguas que debieron retirarse pero siguen activas, normalmente sin los controles de seguridad nuevos. Ambas corresponden al riesgo API9 y se controlan con un inventario vivo.
¿Cada cuánto debo probar la seguridad de mi API?
Integra pruebas automáticas en cada despliegue y haz un pentesting manual al menos una vez al año y después de cambios grandes, como una nueva versión de la API, un nuevo rol de usuario o un flujo de pagos. Las fallas de autorización suelen aparecer justo cuando se añaden funciones nuevas sobre una base existente.
Conclusión
La mayoría de incidentes en APIs no requiere técnicas sofisticadas: basta con cambiar un ID, un campo o un rol que el servidor no verifica. Empieza por un inventario, una matriz de autorización y límites de consumo, y valida con pruebas manuales lo que las herramientas no ven. Si quieres que evaluemos tu API o tu app con su backend, conoce nuestro servicio de ciberseguridad o agenda una consulta gratuita.