¿Qué es una auditoría de seguridad de API?

¿Qué es una auditoría de seguridad de API?

Una auditoría de seguridad de API es una revisión estructurada del diseño, la implementación y la configuración de una API frente a un conjunto definido de requisitos de seguridad, para encontrar debilidades antes de que lo haga un atacante. Combina un inventario de endpoints, escaneos automáticos y pruebas manuales, y termina con una lista priorizada de hallazgos con sus correcciones y una nueva prueba.

En la práctica los términos se solapan. Un escaneo es automático y encuentra clases de fallos conocidas. Una prueba de penetración intenta explotar las debilidades. Una auditoría contrasta la API con un estándar declarado y suele usar ambas cosas, además de revisar diseño, configuración y documentación. Acuerde el alcance y la terminología con quien contrate o con quien se lo pida.

Los estándares frente a los que se audita

La mayoría de las auditorías parten del OWASP API Security Top 10 (2023), una lista de concienciación con los riesgos más críticos de las API (los nombres se usan habitualmente en inglés):

1. API1:2023 Broken Object Level Authorization
2. API2:2023 Broken Authentication
3. API3:2023 Broken Object Property Level Authorization
4. API4:2023 Unrestricted Resource Consumption
5. API5:2023 Broken Function Level Authorization
6. API6:2023 Unrestricted Access to Sensitive Business Flows
7. API7:2023 Server Side Request Forgery
8. API8:2023 Security Misconfiguration
9. API9:2023 Improper Inventory Management
10. API10:2023 Unsafe Consumption of APIs

Para una lista de comprobación más profunda, el OWASP Application Security Verification Standard (ASVS, versión 5.0.0 publicada el 30 de mayo de 2025) recoge requisitos de seguridad y está pensado como base para probar los controles técnicos de seguridad de aplicaciones web. La OWASP Web Security Testing Guide explica cómo probarlos. Nuestra entrada sobre los principales riesgos de seguridad de API explica los riesgos en sí, y seguridad de API cubre el tema general.

Un ejemplo: autorización rota a nivel de objeto

El escenario propio de OWASP para API1 es una API de comercio electrónico con un endpoint como /shops/{shopName}/revenue_data.json. Un atacante obtiene la lista de nombres de tienda de otro endpoint y sustituye cada uno en la URL. Si el servidor solo comprueba que quien llama ha iniciado sesión, y no que la tienda le pertenece, el script lee los ingresos de miles de tiendas. Un escáner rara vez lo detecta, porque cada respuesta es un 200 válido. Un auditor lo prueba llamando al endpoint como un usuario con los identificadores de otro. La solución es una comprobación de propiedad en cada función que recibe un ID aportado por el cliente.

Cómo se desarrolla una auditoría

1. Alcance e inventario. Liste todas las API y versiones: archivos OpenAPI, registros del gateway, código y tráfico. Véanse descubrimiento de API y proliferación de API. No se puede auditar un endpoint cuya existencia nadie conoce.
2. Elegir el estándar. OWASP API Top 10, ASVS o su propia política.
3. Escaneo automático. Ejecute un escáner contra un entorno de pruebas para cubrir rápido las clases de fallos conocidas.
4. Pruebas manuales. Los fallos de autorización necesitan cuentas de prueba reales con distintos roles, para que el auditor pueda preguntar: "¿puede el usuario A llegar a los datos del usuario B?".
5. Clasificación. Valore cada hallazgo por impacto y facilidad de explotación y asigne responsables.
6. Corregir y volver a probar. Confirme que la corrección cierra el problema y no rompe otra cosa.
7. Informe. Hallazgos, evidencias, gravedad y remediación, con un resumen breve para quien no es técnico.

Qué se revisa

• Autenticación: validación de tokens, caducidad, gestión de credenciales, protección frente a fuerza bruta.
• Autorización: comprobaciones a nivel de objeto, propiedad y función en cada endpoint, no solo en el inicio de sesión.
• Tratamiento de entradas: inyección, límites de tamaño de las peticiones, validación de esquemas, peticiones del servidor construidas con datos del usuario.
• Límites de recursos: límites de frecuencia, topes de paginación, operaciones costosas.
• Exposición de datos: campos devueltos que el solicitante no debería ver, tokens o datos personales en los registros, mensajes de error que revelan detalles internos.
• Configuración: cifrado en tránsito, CORS, modos de depuración, credenciales por defecto.
• Inventario y terceros: versiones antiguas olvidadas y cómo trata la API los datos de otras API a las que llama.

Errores comunes

• Auditar solo los endpoints documentados. Las versiones antiguas y las rutas sin documentar son donde están las sorpresas.
• Probar con una sola cuenta de administrador. Los fallos de autorización solo aparecen al cambiar de identidad.
• Límites de frecuencia solo en el gateway. Si se puede llegar directamente al origen, el límite no sirve de nada.
• Una auditoría puntual. La API cambia en cada sprint, así que un informe limpio caduca pronto.
• Escanear sin permiso o en producción. Consiga autorización por escrito y prefiera un entorno de pruebas. Véase la comparativa de herramientas de pruebas de penetración.
• No repetir la prueba. Un hallazgo está cerrado cuando se verifica, no cuando se cierra el ticket.

Relación con la monitorización y las pruebas de carga

LoadFocus no es un auditor de seguridad y no busca vulnerabilidades. Lo que sí puede hacer es seguir vigilando el comportamiento después de que una auditoría haya corregido algo. La monitorización de API ejecuta comprobaciones programadas (cada 5 minutos en el plan gratuito) desde varias de sus 25 regiones y puede verificar código de estado, cuerpo y cabeceras, de modo que una comprobación que espera que se rechace una petición sin token fallará si un despliegue posterior la deja pasar. Las comprobaciones de varios pasos pueden encadenar peticiones, por ejemplo iniciar sesión y luego llamar a otro endpoint. En cuanto al consumo de recursos, una prueba de carga de API gratuita muestra cómo se comporta un endpoint público con volumen (solo peticiones GET, hasta 25 usuarios virtuales desde una ubicación); haga pruebas de carga solo sobre sistemas propios o con permiso. Para una búsqueda más profunda en tráfico real, véase búsqueda de amenazas en API.

Preguntas frecuentes: auditorías de seguridad de API

¿Con qué frecuencia debe auditarse una API?

Antes del lanzamiento, tras cambios importantes en autenticación o tratamiento de datos, y después con una cadencia regular. Como las API cambian constantemente, muchos equipos añaden comprobaciones automáticas entre auditorías completas en lugar de depender de un informe al año.

¿Qué diferencia hay entre una auditoría de seguridad de API y una prueba de penetración?

Los términos se solapan. Una prueba de penetración se centra en intentar explotar debilidades y a menudo abarca más que la API. Una auditoría contrasta con un estándar declarado y cubre diseño, configuración y procesos además de la explotabilidad. Confirme qué incluye cada servicio antes de empezar.

¿Las API solo internas necesitan auditoría?

Sí. Las API internas son accesibles para cualquiera que consiga un punto de apoyo en la red o comprometa un servicio, y merecen la misma autenticación, autorización y registro que las públicas.

¿Qué hay que preparar para una auditoría?

Especificaciones actuales de la API, un inventario de endpoints y versiones, cuentas de prueba para cada rol, un entorno de pruebas y una lista de problemas conocidos. Cuanto más completo el inventario, menos tiempo se pierde en descubrir.

¿Puede un escáner automático sustituir a una auditoría?

No. Los escáneres cubren rápido las clases de fallos conocidas, pero no saben a quién debería pertenecer cada objeto, así que fallos como la autorización rota a nivel de objeto suelen requerir pruebas manuales con varias identidades.