¿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 la revisión sistemática de la superficie de API de una organización para vulnerabilidades — debilidades de autenticación, fallos de autorización, gaps de validación de entrada, gaps de rate-limiting, datos sensibles expuestos y el resto del OWASP API Security Top 10. La auditoría produce una lista priorizada de hallazgos con severidad, complejidad de exploit y guía de remediación. Hecha bien, una auditoría de seguridad de API es la forma más efectiva de sacar a la luz el riesgo real en un stack web moderno — la mayoría de las apps modernas son 80%+ superficie de API, así que las APIs concentran la exposición de seguridad.

Las auditorías de seguridad de API vienen en tres sabores: internas (tu equipo de seguridad ejecutando herramientas + revisión manual), de terceros (firmas especialistas como NCC Group, Bishop Fox, Trail of Bits — usualmente anuales o pre-lanzamiento) y continuas automatizadas (herramientas como Salt, Noname, Wallarm escaneando tráfico de producción continuamente). La mayoría de las orgs maduras usan las tres: continua automatizada para línea base, terceros anualmente para profundidad, internas para remediación continua.

El OWASP API Security Top 10 (edición 2023)

La lista de referencia contra la que toda auditoría de seguridad de API verifica:

1. Broken Object Level Authorization (BOLA) — vuln de API más común. GET /users/123 devuelve los datos del usuario 123 sin verificar que el llamante esté permitido.
2. Broken Authentication — validación débil de tokens, reuso de credenciales, MFA faltante.
3. Broken Object Property Level Authorization — el llamante puede leer o modificar campos de objeto que no debería.
4. Unrestricted Resource Consumption — sin rate limiting, sin cap de tamaño de body; permite DoS.
5. Broken Function Level Authorization — endpoints admin accesibles a no-admins.
6. Unrestricted Access to Sensitive Business Flows — la automatización puede vaciar inventario, abusar cupones, etc.
7. Server-Side Request Forgery (SSRF) — URL controlada por usuario obtenida del lado del servidor alcanza servicios internos.
8. Security Misconfiguration — modo debug en prod, credenciales por defecto, errores verbosos.
9. Improper Inventory Management — versiones API antiguas ejecutándose sin monitorear ("APIs ocultas").
10. Unsafe Consumption of APIs — APIs de terceros confiadas sin validación.

Lo que cubre una auditoría de seguridad de API

Autenticación + autorización

• Validación de token: firma, expiración, scope, audience.
• Gestión de sesión: rotación, revocación, idle timeout.
• Verificaciones de autorización en cada endpoint, incluyendo nivel objeto (BOLA).
• Límites de roles + permisos aplicados consistentemente.

Validación de entrada

• SQL injection, NoSQL injection, command injection, LDAP injection.
• SSRF / XXE / riesgos de deserialización.
• Límites de tamaño de body + aplicación de content-type.
• Validación de esquema JSON.

Rate limiting + prevención de abuso

• Rate limits por usuario / por IP / por endpoint.
• Protección contra fuerza bruta en endpoints de auth.
• CAPTCHA + detección de bots donde sea apropiado.

Exposición de datos

• Response shaping (no devolver hashes de contraseña, IDs internos).
• Disciplina de logging (no loguear tokens, PII).
• Higiene de mensajes de error (no filtrar stack traces, planes de query).

Inventario + ciclo de vida

• Catalogar todos los endpoints (incluyendo v1, v2, internos). Ver API sprawl.
• Sunset versiones antiguas según horario.
• Detectar APIs ocultas (desplegadas sin pasar por gateway).

Cómo se desarrolla una auditoría típica

1. Fase de inventario. Catalogar todas las APIs (logs de gateway, specs OpenAPI, grep de código, descubrimiento de tráfico).
2. Escaneo automatizado. Herramientas como OWASP ZAP, Burp Suite Pro, StackHawk, Salt ejecutan pruebas automatizadas.
3. Pruebas manuales. Los auditores apuntan al OWASP Top 10 manualmente — las herramientas automatizadas pierden BOLA, abuso de lógica de negocio y flujos auth complejos.
4. Hallazgos + scoring de severidad. CVSS o scoring de riesgo propietario; usualmente CRITICAL/HIGH/MEDIUM/LOW.
5. Remediación. Arreglos de ingeniería, con seguimiento hasta verificado.
6. Re-test. Verificar que los hallazgos están realmente cerrados; común encontrar regresiones.
7. Reporte. Resumen interno + ejecutivo; a veces un resumen público sanitizado para revisión de cliente/regulador.

Hallazgos comunes de auditoría de seguridad de API

• BOLA en recursos REST. Mass assignment / exposición directa de ID sin verificaciones de acceso.
• Errores verbosos filtrando stack traces. Producción nunca debería exponer stack traces internos.
• Rate limiting solo en gateway. Si los usuarios pueden golpear origin directamente, los rate limits no significan nada.
• Gaps de validación JWT. Saltar verificación de firma, aceptar alg: none, claves HMAC débiles.
• Mishandling de scope OAuth. El token concede más acceso del previsto; los refresh tokens nunca expiran.
• TLS faltante en llamadas internas. Dentro de la VPC ≠ seguro; las llamadas internas merecen mTLS o al menos TLS autenticado.
• Deserialización insegura. Especialmente en rutas pickle más antiguas Java / .NET / Python.
• Protecciones CORS / CSRF faltantes en endpoints orientados al navegador.

FAQ: Auditorías de Seguridad de API

¿Con qué frecuencia debería ejecutar una auditoría de seguridad de API?

Escaneo automatizado continuo todo el tiempo. Revisión interna por release. Tercero anualmente + antes de cualquier lanzamiento mayor. No te bases solo en anual — las APIs cambian demasiado rápido.

¿Cuál es la diferencia entre una auditoría de seguridad de API y un pen test?

El penetration testing es más amplio (red, infraestructura, ingeniería social). Una auditoría de seguridad de API es específica de API. La mayoría de las empresas ejecutan ambas — pen tests anuales, auditorías API por release/continuas.

¿Cuánto tarda una auditoría de seguridad de API?

Interna automatizada: horas. Tercero exhaustiva: 2-6 semanas para una superficie de API SaaS típica. El tiempo escala con conteo de API + complejidad.

¿Cuánto cuesta una auditoría de seguridad de API?

Tercero exhaustiva: 20k-200k $ dependiendo de alcance + reputación de la firma. Herramientas continuas automatizadas: 20k-200k $/año. Trabajo interno: variable.

¿Cómo me preparo para una auditoría?

Specs OpenAPI actualizadas, inventario API actual, threat model reciente, lista de issues conocidos, acceso para los auditores (credenciales de prueba, acceso al gateway, repo de código). Los auditores odian empezar desde cero.

¿Qué hay sobre las APIs solo internas?

Audítalas también. "Interno" no significa seguro — la mayoría del movimiento lateral en brechas pasa a través de APIs internas. Aplica los mismos estándares.

¿Cómo se relaciona la auditoría de seguridad de API con SOC 2 / ISO 27001?

Ambos frameworks requieren alguna forma de gestión de vulnerabilidades, a menudo satisfecha por una cadencia de auditoría de seguridad de API documentada. Los auditores pedirán evidencia de testing + remediación regular.

Cómo se relaciona LoadFocus con la validación de seguridad de API

Las auditorías de seguridad de API sacan a la luz vulnerabilidades en un punto en el tiempo. La monitorización de API LoadFocus valida la salud continua — incluyendo verificaciones de aserción que atrapan regresiones en el manejo de auth/authz (p.ej., un despliegue que rompe la protección BOLA silenciosamente). Las pruebas de carga de API validan que el rate-limiting y la protección DoS realmente funcionan bajo patrones de carga similares a ataques — muchos rate limits se ven correctos en revisión de código pero fallan a escala.