OWASP API Top 10 (2023) · ASVS · CVSS 4.0 · PCI DSS · DORA · NIS2 · ISO 27001
Auditoría de seguridad de APIs REST y GraphQL
Auditoría manual + automatizada sobre tu API. Cobertura OWASP API Top 10 (2023): BOLA, BFLA, BOPLA, exposición masiva, rate limiting, autenticación JWT/OAuth/mTLS, abuso de endpoints. Y, sobre todo, lógica de negocio expuesta a través de la API que ningún escáner detecta. Cada hallazgo con evidencia, severidad CVSS 4.0 y remediación priorizada por riesgo real.
Resumen ejecutivo
Tu API es probablemente el componente más expuesto y a la vez más crítico de tu producto: se consume desde frontend web, móvil, integraciones B2B y terceros. Una auditoría de API hecha en serio cubre OWASP API Top 10 (2023) completo, valida la autenticación y autorización a nivel de objeto, función y propiedad, mide resistencia a abuso y, sobre todo, prueba la lógica de negocio expuesta que ningún escáner detecta.
Los proyectos típicos en Hard2bit cierran entre 7 y 35 días laborables según complejidad, con notificación inmediata de hallazgos críticos y revalidación posterior incluida en el alcance. El informe se entrega listo para sostener auditoría externa: PCI QSA si toca CDE, supervisor financiero para DORA, certificador ISO 27001, auditor ENS para servicios públicos, requirement de cliente enterprise.
OWASP API Top 10 + lógica
Cobertura completa del estándar + verificación humana de la lógica de negocio expuesta. Donde un escáner ve estructura, el auditor ve abuso.
Auditor-ready
Informe pensado para que pase auditoría externa: PCI QSA, ISO 27001, ENS, DORA, supervisor financiero, exigencias de cliente enterprise.
Remediación útil
Cada hallazgo con regla de mitigación inmediata (WAF/API Gateway) + remediación de código. Para que puedas contener mientras desarrollo arregla.
Qué cubrimos en una auditoría de API
La base es OWASP API Security Top 10 (2023) completo más las áreas adicionales que ese estándar deja fuera pero que aparecen en proyectos reales.
API1 — BOLA (Object Authorization)
Bypass de autorización a nivel de objeto: cambiar un ID en URL/payload y acceder a recursos de otro usuario o tenant. La vulnerabilidad #1 en APIs modernas.
API2 — Broken Authentication
JWT mal firmado o sin verificar, OAuth client-side, tokens largos sin expiración, refresh tokens sin rotación, login bypass, recuperación de contraseña vulnerable.
API3 — BOPLA (Property Auth)
Mass assignment: enviar campos protegidos (isAdmin=true, role=manager, balance=999999) que el backend acepta sin filtrar. Y a la inversa: exposición de propiedades sensibles en respuestas.
API4 — Unrestricted Resource Use
Sin rate limiting, sin tamaño máximo de payload, sin profundidad máxima en GraphQL: abuso para denial-of-wallet (consumo masivo) o DoS.
API5 — BFLA (Function Auth)
Bypass de autorización a nivel de función: endpoints admin accesibles para usuarios normales, escalada de privilegios cambiando verbo HTTP o ruta.
API6 — Unrestricted Business Flows
Abuso de flujos legítimos sin protección: comprar productos limitados en cantidad masiva, crear cuentas masivas, drenar inventario, manipular pricing en checkout.
API7 — SSRF en API
Endpoints que aceptan URLs como parámetro y permiten redirigir peticiones a metadata cloud (IMDS), servicios internos o segmentos privados.
API8 — Misconfiguration
CORS abierto al mundo, headers sin Cache-Control en respuestas sensibles, errores verbosos con stack trace, métodos HTTP innecesarios habilitados.
API9 — Improper Inventory
APIs antiguas (v1, v2) sin documentar pero accesibles, endpoints internos expuestos por descuido, documentación obsoleta que oculta endpoints reales.
API10 — Unsafe API Consumption
Tu API confía en APIs de terceros sin validar respuestas: vector de cadena de suministro cuando ese tercero se ve comprometido.
Autenticación entre servicios
Microservicios: mTLS bien configurado, OAuth client_credentials con scope mínimo, JWT entre servicios sin validar firma, secretos compartidos sin rotación.
GraphQL específico
Query complexity attacks, batching abuse, introspection abusiva, autorización a nivel de campo, errores verbosos que filtran esquema.
Anatomía de un hallazgo crítico
Patrón técnico real de un hallazgo BOPLA con escalada de privilegios. Anonimizado, basado en un proyecto real sobre API REST de plataforma SaaS B2B.
Descubrimiento
Mass assignment en POST /api/v3/orders
El endpoint aceptaba el payload completo de la entidad Order al crearla, sin filtrar
propiedades sensibles. Enviando { "items": [...], "total": 0.01, "status": "PAID" }
el backend persistía el pedido con total manipulado y status PAID sin verificar pago.
El frontend nunca enviaba esos campos pero el backend los aceptaba sin validar
ownership ni whitelist de propiedades.
Severidad
CVSS 4.0 = 9.0 (Crítica)
AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N. Red, complejidad baja, requiere cuenta autenticada (cualquier usuario registrado). Impacto: integridad alta (pedidos creados sin pago, sin fraude detectado en sistemas de billing porque el flujo legítimo se salta). Confidencialidad y disponibilidad no afectadas. El impacto de negocio era superior al CVSS sugiere: cualquier cliente podía pedir productos sin pagar.
Evidencia
Prueba sin abuso real
Demostración con cuenta de prueba creada para el proyecto, en entorno de preproducción con configuración idéntica a producción. Captura del request/response, log del backend mostrando aceptación del payload, captura del registro en base de datos. No se ejecutaron pruebas en producción para evitar inconsistencias en billing real.
Remediación
Mitigación + parche definitivo
Inmediato (6 horas): regla en API Gateway descartando propiedades total y status del payload entrante. Medio plazo (1 semana): parche en código usando DTO de entrada limitado a campos del cliente (items, billingAddress, shippingAddress); el resto se calcula server-side. Largo plazo: auditoría de todos los endpoints POST/PUT/PATCH buscando el mismo patrón. Se encontraron otros 5 endpoints con mass assignment.
Caso técnico anonimizado basado en patrones reales de SaaS B2B con e-commerce embebido. Sector, magnitudes y nombres alterados. Sin NDAs públicos, sin nombre de cliente.
Cuándo encaja y cuándo no
Encaja muy bien
Cuándo merece la pena
- Tu API es la pieza central del producto (SaaS B2B, fintech, healthtech, marketplace)
- API pública consumida por terceros o por aplicación móvil propia
- Sale a producción una API v2 o cambia el modelo de autenticación
- Multi-tenant: validar aislamiento entre clientes
- Auditor exige evidencia: PCI DSS, DORA, NIS2, ISO 27001, contrato enterprise
- Migración a microservicios o paso a GraphQL
- Post-incidente: hubo fuga, abuso o suplantación a través de API
Encaja menos
Cuándo no es lo primero
- API en fase de prototipo sin tráfico real: dejarla madurar primero
- Si tu producto es esencialmente web y la API es solo BFF interno menor: auditoría web ya la cubre
- El problema viene de proceso de desarrollo (secretos en repos, sin code review): empezar por auditoría de código
- Necesitas vigilancia continua, no puntual: combinar con superficie de ataque
- Tras un incidente activo, primero respuesta a incidentes; auditoría después
Cómo lo entregamos
Cuatro fases reales, con notificación inmediata de críticos. Para APIs públicas con tráfico activo esto cambia el coste real del proyecto: la contención empieza el día que se detecta, no al final del informe.
1. Walkthrough técnico (1-2 días)
Sesión con desarrollador que mantiene la API. Revisamos OpenAPI spec o Postman collection si existe; si no, mapeamos endpoints en sesión. Acordamos alcance, ventana, IPs origen, plan de comunicación con TI/SOC, y modelo de cuentas de prueba (especialmente importante en SaaS multi-tenant para verificar aislamiento).
2. Auditoría manual + automatizada (60-80% del tiempo)
Burp Suite Pro, postman/Bruno, scripts propios. Para GraphQL añadimos InQL y graphw00f. Pruebas exhaustivas de autenticación (manipulación de JWT, OAuth flows, refresh), autorización (BOLA/BFLA/BOPLA), rate limiting, lógica de negocio expuesta. Críticos notificados al instante con regla de mitigación inmediata propuesta.
3. Documentación y verificación
Cada hallazgo con request/response, CVSS 4.0, impacto de negocio, exploit de prueba, recomendación de remediación de código + regla de mitigación inmediata para WAF/API Gateway. Verificación doble para evitar falsos positivos en el informe final.
4. Cierre y revalidación
Sesión de 90 minutos con desarrollo y operación de la API. Discusión de hallazgos, plan de remediación, prioridad real. Si se contrata, revalidación a las 4-8 semanas certificando que las correcciones funcionan y emitiendo carta de verificación apta para auditor externo.
Qué incluye el paquete documental
1. Informe técnico
Cada hallazgo con descripción, request/response, CVSS 4.0, impacto de negocio, recomendación de remediación de código + regla de mitigación inmediata para WAF/API Gateway.
2. Informe ejecutivo
2-3 páginas sin jerga técnica. Hallazgos en términos de negocio, riesgo agregado, plan de acción. Apto para consejo o cliente enterprise.
3. Matriz priorizada
Hallazgos ordenados por riesgo real: exposición + explotabilidad + impacto + esfuerzo de remediación. Lista accionable para desarrollo.
4. Reglas de mitigación
Para los hallazgos que se pueden contener en WAF/API Gateway (rate limiting, denegación de payloads, headers): reglas listas para aplicar en Cloudflare, AWS API Gateway, Kong, Apigee.
5. Repositorio de evidencias
ZIP firmado con timestamps, request/response capturados, scripts de prueba, logs. Para auditor externo o cliente regulado.
6. Sesión de cierre + revalidación
90 minutos con desarrollo. Si se contrata revalidación: segunda pasada + carta de verificación apta para auditor externo o cliente enterprise.
Adaptación por sector
SaaS B2B y plataformas
Foco intensivo en aislamiento multi-tenant, OAuth, BOLA/BFLA/BOPLA. Compatible con SOC 2 si aplica. Casi siempre exige también evidencia para responder cuestionarios de seguridad de clientes enterprise.
Fintech y entidades financieras
Cumplimiento DORA (art. 24-27) sobre testing de resiliencia. PCI DSS 6.4.3 y 11.4.3 si toca CDE. Foco en flujos de pago, prevención de fraude, race conditions en transferencias, autenticación reforzada (SCA).
Healthtech y plataformas sanitarias
Foco en exposición de datos especiales (RGPD art. 9), integraciones HL7/FHIR, autorización por rol médico, auditoría de accesos. Si aplica ENS Alta (operadores esenciales): op.exp.5.
AAPP y servicios públicos digitales
Cumplimiento ENS según categorización. Identidad con Cl@ve, certificados digitales, accesibilidad cuando aplique. Plataformas que consumen ciudadanos requieren foco en privacidad y datos especiales.
Plataformas con marketplace o terceros
API consumida por partners externos: foco en autenticación entre servicios, scope mínimo de OAuth, rate limiting por consumidor, vigilancia de uso anómalo. Encaje con NIS2 art. 21 (gestión de riesgo TIC) y terceros.
Aplicaciones móviles con backend propio
Foco en certificate pinning, cifrado de tráfico, almacenamiento seguro de tokens en cliente, ofuscación de secretos en bundles, validación server-side de todo lo que el cliente envía.
Encaje regulatorio
La auditoría de API es exigida (a veces de forma implícita) por todos los marcos relevantes para empresa en España. El informe se entrega apto para sostener auditoría externa.
| Marco | Referencia | Qué exige y cómo lo cubrimos |
|---|---|---|
| DORA | Art. 24-27 | Programa de pruebas de resiliencia digital sobre sistemas TIC críticos. APIs son piezas centrales: la auditoría cubre el requisito y produce evidencia para supervisor. |
| PCI DSS v4.0.1 | Req. 6.4.3 y 11.4.3 | Validación de aplicaciones públicas (incluye APIs) y pentest anual sobre CDE. Apto para PCI QSA. |
| NIS2 | Art. 21.2.f | Políticas y procedimientos para evaluar la eficacia de las medidas. Periodicidad documentada y trazabilidad. |
| ISO 27001:2022 | A.8.29 | Testing de seguridad en el ciclo de desarrollo, incluyendo APIs. Evidencia trazable para certificación. |
| ENS (Alta) | op.exp.5 | Pruebas técnicas periódicas con documentación de hallazgos y remediación. Apto para auditoría ENS. |
| RGPD | Art. 32.1.d | Verificación regular de la eficacia de medidas técnicas. Especialmente relevante si la API procesa datos especiales (art. 9). |
| Open Banking PSD2 | RTS art. 8 | APIs de pago: autenticación reforzada, gestión de excepciones, monitorización. La auditoría valida los controles. |
Lo que solemos hacer y otros no
Mitigación inmediata + parche de código
Cada hallazgo viene con una recomendación de regla WAF/API Gateway aplicable en horas + el parche de código definitivo. Eso te permite contener antes de que desarrollo libere fix.
Notificación inmediata de críticos
Si hay BOLA explotable en API pública con tráfico real, te llamamos. No esperamos al informe final para que pierdas dos semanas más expuesto.
Validación de aislamiento multi-tenant
En SaaS B2B verificamos que un tenant no puede acceder a datos de otro, con cuentas de prueba en distintos tenants del cliente. Es el riesgo #1 y rara vez se prueba bien.
Revisión de autenticación entre servicios
En microservicios revisamos mTLS, OAuth client_credentials, JWT inter-servicio, secretos compartidos. Es donde se ha visto más compromiso lateral en 2024-2025.
GraphQL con metodología propia
InQL + graphw00f + trabajo manual exhaustivo sobre el esquema. Query complexity, batching abuse, autorización a nivel de campo. La mayoría de auditorías de API tratan GraphQL como REST y se pierden la mitad.
Tests con WAF/Gateway activo
No desactivamos WAF para inflar hallazgos. Auditamos con la realidad de tu producción + ventana sin WAF para cobertura máxima. Saber qué bloquea WAF también es valor.
Objeciones que escuchamos y cómo las contestamos
«Nuestra API es interna, no la auditamos»
El argumento funciona solo mientras nadie esté dentro de tu red. El día que un atacante entra por una cadena de suministro, un empleado comprometido o un microservicio vulnerable, tus APIs internas son su mejor palanca de pivot. NIS2 y DORA recogen esta lógica: piden controles sobre TODOS los servicios TIC críticos.
«Ya pasamos un escáner DAST mensual sobre la API»
Bien. Pero el DAST no detecta BOLA en tu modelo de datos, ni BOPLA porque no sabe qué campos están protegidos, ni abuso de lógica de negocio porque no entiende qué es un pedido legítimo. Cubrís bien la superficie ancha; nosotros cubrimos lo que está oculto a la herramienta.
«Tenemos tests automáticos en CI, ya cubrimos seguridad»
Los tests de CI validan funcionalidad bajo casos esperados. Un atacante no juega bajo casos esperados: prueba combinaciones que el desarrollador no consideró. Un test de CI nunca encontrará un BOLA porque el equipo que escribió el test sabe que la app filtra por tenant. El atacante prueba qué pasa si NO lo hace.
«Es caro. ¿Compensa para una API mediana?»
Una API SaaS multi-tenant comprometida con BOLA filtra datos personales: notificación al supervisor (potencial 4% facturación), pérdida de clientes enterprise por incumplimiento contractual, DFIR (15-50 k€), remediación urgente (40-80 k€), reputación. Una auditoría de 12-20 k€ que evita esto es la inversión más rentable del año.
«Nuestra API es REST simple, no necesitamos auditoría dedicada»
Los hallazgos más críticos modernos son BOLA, BFLA y BOPLA. Aparecen en REST simple igual que en GraphQL complejo. Si tu API gestiona dinero, datos personales o decisiones de negocio, mereces la auditoría dedicada. Si es solo BFF interno para una web pequeña, un capítulo dentro de auditoría web la cubre.
«No tenemos OpenAPI spec, ¿podéis auditar igual?»
Sí. Mapeamos los endpoints en walkthrough técnico inicial, con desarrollador o con Postman collection. Tarda 1-2 horas más, no cambia el resultado. De hecho, en auditorías sin spec a veces encontramos endpoints olvidados que el equipo de seguridad no sabía que existían (API9 — Improper Inventory).
Cómo medimos calidad de nuestras auditorías de API
Seis indicadores que comparamos contra benchmark propio histórico. Se comparten en sesión de cierre para que tu equipo vea cómo ha quedado el proyecto frente al estándar interno.
Cobertura OWASP API Top 10
Porcentaje de las 10 categorías testadas a fondo. Objetivo: 100% en auditorías estándar.
Endpoints/día auditor
Productividad y profundidad. Demasiados endpoints/día = cobertura superficial.
Ratio BOLA/BFLA detectado
En APIs con autenticación, si no detectamos al menos uno, sospechamos cobertura insuficiente y revisamos metodología.
Tiempo de notificación crítico
Horas desde detección de un hallazgo crítico hasta notificación al cliente. Objetivo: <6 horas en API pública, <12 horas en API interna.
Falsos positivos en informe
Porcentaje de hallazgos rechazados por cliente tras verificación. Objetivo: <3%.
Tasa de revalidación cerrada
Porcentaje de hallazgos que el cliente cierra realmente en revalidación. Indicador de calidad de las recomendaciones.
Errores habituales al contratar una auditoría de API
- Asumir que un escáner DAST cubre las APIs. Detecta inyección y XSS, pero ni un solo BOLA/BFLA/BOPLA porque no sabe qué es legítimo en tu modelo de datos.
- Auditar solo la API pública e ignorar las internas. El día que alguien entre por una cadena de suministro, las internas son el camino preferido.
- Hacer auditoría sin OpenAPI spec ni Postman collection y sin desarrollador disponible. El auditor pierde 30% del tiempo mapeando endpoints; el coste/valor cae.
- No probar el aislamiento multi-tenant en SaaS B2B. Es el riesgo #1 de tu producto y rara vez se valida bien si no se exige explícitamente.
- Tratar GraphQL como REST. Necesita metodología propia: complejidad, batching, introspection, autorización a nivel de campo.
- No revalidar tras remediar. Sin segunda pasada, el informe es papel mojado para auditor regulado o cliente enterprise.
- Confundir CVSS alto con prioridad. Un CVSS 9 en endpoint interno sin tráfico puede ser menos urgente que un CVSS 6 en API pública con 10k req/s.
- Aceptar auditoría barata sin walkthrough técnico previo. Sin entender la API, cualquier presupuesto es inventado.
Glosario rápido de la jerga de API security
OWASP API Top 10
Ranking de las 10 categorías de vulnerabilidades más críticas en APIs. Actualizado en 2023.
BOLA
Broken Object Level Authorization. Acceso a recursos cambiando un ID sin que el backend valide ownership. #1 en APIs.
BFLA
Broken Function Level Authorization. Acceso a funciones administrativas desde cuenta sin privilegios.
BOPLA
Broken Object Property Level Authorization. Mass assignment (entrada) o exposición masiva (salida) de propiedades.
Rate limiting
Límite de peticiones por unidad de tiempo y origen. Previene abuso, brute force, denial-of-wallet.
JWT
JSON Web Token. Token de autenticación firmado. Vulnerable si la firma se debilita o no se verifica.
OAuth 2.0 / OIDC
Protocolos de autorización (y autenticación con OIDC) estándar para APIs. Múltiples flows: authorization code, client credentials, etc.
mTLS
Mutual TLS. Autenticación mutua entre cliente y servidor con certificados. Común entre microservicios.
GraphQL introspection
Capacidad de consultar el esquema completo de una API GraphQL. Desactivar en producción.
Query complexity attack
GraphQL: consultas anidadas o con tipos cíclicos que generan carga exponencial en el servidor.
API Gateway
Capa entre clientes y APIs internas. Puede aplicar autenticación, rate limiting, transformación, observabilidad.
Denial-of-wallet
Abuso de APIs que cobran por consumo (cloud, LLM, terceros) para generar coste al objetivo.
Servicios relacionados en Hard2bit
Pentesting
Servicio madre. Auditoría de API es una disciplina dentro del pentesting enterprise.
Ver →
Auditoría aplicaciones web
Complementaria. Si tu producto se ataca por web y por API, conviene auditar ambos en mismo proyecto.
Ver →
Auditoría de código fuente
Encuentra fallos invisibles desde fuera: lógica defectuosa, secretos hardcoded, dependencias vulnerables.
Ver →
Identidades no humanas
Tokens, API keys, OAuth client credentials, secretos: el otro 50% del riesgo moderno de API.
Ver →
Gestión riesgo de terceros
Si tu API consume APIs de terceros (o al revés), el riesgo es cadena. Programa para gestionarlo.
Ver →
Superficie de ataque
Vigilancia continua tras la auditoría: detectar APIs nuevas que el equipo de desarrollo expone sin avisar.
Ver →
Auditoría integral
Cuando además de API hay infraestructura, identidad, cloud y procesos: un único proyecto.
Ver →
Seguridad cloud
Si tu API vive en cloud, complementaria: postura IAM, exposición de servicios, secretos en pipelines.
Ver →
Respuesta a incidentes
Si la auditoría revela compromiso activo en la API, escalado inmediato a respuesta.
Ver →
Preguntas frecuentes
¿En qué se diferencia auditar una API de auditar una aplicación web?
La aplicación web es la fachada, la API es donde vive el negocio. Una auditoría web cubre lo que el usuario ve; una auditoría de API entra en la capa donde se materializan los riesgos modernos: autorización a nivel de objeto (BOLA), a nivel de función (BFLA), a nivel de propiedad (BOPLA), exposición masiva de atributos, abuso de endpoints sin rate limiting, errores de autenticación entre servicios. Cuando el mismo producto se ataca desde frontend web y desde aplicación móvil, la API es el punto común; auditarla bien protege ambos canales con un único proyecto. Si la API es la pieza central de tu producto, la auditoría dedicada tiene más profundidad que cualquier capítulo dentro de una auditoría web genérica.
¿Qué metodología seguís y qué referencia normativa usáis?
Combinamos OWASP API Security Top 10 (2023) como check de mínimos, OWASP ASVS L2/L3 para criterios de verificación cuando hay aplicación cliente asociada, y los principios de OWASP API Security Project para alcance amplio. Sobre eso añadimos verificación manual de la lógica de negocio expuesta a través de la API (que es donde no llega ningún escáner), tests específicos para JWT/OAuth/SAML cuando corresponda, validación de aislamiento multi-tenant si la API es SaaS, y revisión de mTLS o tokens client-credentials para autenticación entre servicios. En entornos regulados añadimos los requisitos específicos: PCI DSS 6.4.3 si toca CDE, DORA artículos 24-27 si es entidad financiera, NIS2 artículo 21.2 para servicios esenciales.
¿Cuánto dura una auditoría de API típica y cuánto cuesta?
Una API REST con 20-40 endpoints, 2-3 perfiles de cliente y autenticación estándar (JWT u OAuth) se audita en 7-14 días laborables con 1-2 auditores. Coste orientativo en España: 7.500-18.000 euros. APIs grandes (100+ endpoints, multi-tenant, GraphQL complejo, mTLS, integraciones con muchos servicios) se mueven en 20-35 días y 25-45 mil euros. Si tu API es pública y la consumen terceros (típico en fintech, healthtech, plataformas), el coste sube porque cada consumidor abre vectores distintos. Pedimos siempre acceso a la API y, si existe, OpenAPI spec o Postman collection antes de presupuestar firme; sin eso, cualquier número es inventado.
¿Cómo auditáis una API GraphQL? ¿Es muy distinto de REST?
Sí, requiere otro enfoque. GraphQL expone un solo endpoint con un esquema flexible que cliente compone a su gusto, lo que abre vectores específicos: introspection abusiva del esquema, query complexity attacks (consultas anidadas que tumban backend), authorization bypass a través de campos no validados, batching abuse y información sensible expuesta por errores demasiado verbosos. Usamos herramientas específicas (InQL, GraphQL Cop, graphw00f para fingerprinting) y trabajo manual exhaustivo sobre el esquema. La cobertura típica de OWASP API Top 10 sigue aplicando pero se complementa con riesgos propios de GraphQL.
¿Hace falta entorno de preproducción o auditáis APIs en producción?
Preferimos preproducción con datos representativos. Producción es viable con plan acordado, IPs origen, límite de carga y exclusión de pruebas destructivas (DoS, mass DELETE, modificación masiva de datos). Si la API es financiera o sanitaria, suele ser preproducción obligatoria porque los reguladores no admiten pruebas en datos personales reales. Para APIs SaaS multi-tenant generamos siempre cuentas de prueba en tenants distintos del cliente final para verificar aislamiento sin tocar datos reales.
¿Qué entregables damos al final del proyecto?
El mismo paquete que en otras auditorías: informe técnico con cada hallazgo (descripción, evidencia con request/response, criticidad CVSS 4.0, impacto de negocio, recomendación), informe ejecutivo de 2-3 páginas para dirección, matriz priorizada por riesgo real, repositorio de evidencias firmado con timestamps para auditor externo, y sesión de cierre con TI y desarrollo. Adicional para API: colección Postman/Bruno o spec OpenAPI actualizada si el cliente lo necesita para integraciones internas, reglas de WAF/API Gateway propuestas para mitigar mientras se remedia código. Revalidación posterior incluida si se contrata.
¿Sirve como evidencia para PCI DSS, DORA, NIS2 o ISO 27001?
Sí, cuando se documenta correctamente. PCI DSS v4 (req. 6.4.3 y 11.4.3) exige pruebas sobre APIs accesibles si tocan el CDE. DORA (artículos 24-27) regula pruebas de resiliencia digital sobre sistemas TIC críticos, donde las APIs son piezas centrales. NIS2 (art. 21.2.e/f) exige políticas de gestión y evaluación de la eficacia de las medidas. ISO 27001:2022 (A.8.29) requiere testing de seguridad en el ciclo de desarrollo. El informe técnico + matriz + evidencias con timestamps cumple los cuatro marcos y es apto para QSA, auditor ISO, organismo ENS o supervisor financiero.
Nuestras APIs son internas, no públicas. ¿Sigue mereciendo la pena auditarlas?
Casi siempre sí. APIs internas son el camino preferido del atacante una vez compromete una pieza periférica (típico en cadena de suministro, cuenta de empleado comprometida, microservicio vulnerable). El argumento 'no son públicas' funciona mientras nadie esté dentro de tu red, lo cual deja de ser cierto el primer día que pasa algo. En auditorías recientes hemos visto APIs internas que asumían confianza implícita: sin autenticación, sin autorización, log limitado. El día que un atacante llega a ese punto, esas APIs son la palanca de pivot. NIS2 y DORA recogen esta lógica obligando a controles sobre TODOS los servicios TIC críticos, no solo los externos.
¿Qué hacéis si encontráis algo crítico durante la auditoría?
Notificación inmediata por canal acordado previamente (mail cifrado, Signal, llamada). No esperamos al informe final. El cliente recibe el hallazgo con descripción, evidencia, impacto estimado y recomendación de contención temporal (típicamente: regla de WAF/API Gateway que mitiga mientras se remedia código). Si el cliente lo solicita, ayudamos a coordinar remediación urgente con su equipo de desarrollo. La distancia entre 'reportamos al final' y 'reportamos al detectar' son semanas de exposición que se evitan, especialmente en APIs públicas con tráfico activo.
¿Cómo arrancamos un proyecto en Hard2bit?
Empezamos con una llamada de 30 minutos para entender la API, los consumidores, el alcance, el modelo de autenticación, el momento del ciclo (release, post-incidente, exigencia regulatoria) y el objetivo del cliente. Si tiene sentido, agendamos walkthrough técnico de 1 hora con el responsable de la API (lo ideal: con desarrollador que la mantenga). Con eso emitimos propuesta firme en 48-72 horas: alcance, ventana, equipo asignado, entregables y precio cerrado. Sin compromisos hasta la firma.
¿Tienes una API que necesita auditoría?
Llamada de 30 minutos para entender la API, los consumidores, el modelo de autenticación y el momento del ciclo. Si tiene sentido, propuesta firme en 48-72 horas. Sin compromisos hasta la firma.