Parte: 11 — DevSecOps y seguridad del SDLC · Fuente: OWASP API Security Top 10 (2023) y OWASP ASVS v4 ⏱️ Duración estimada: 120 min · Nivel: Avanzado
Integrar la seguridad de APIs en cada fase del desarrollo: diseñar contratos seguros (OpenAPI), prevenir las vulnerabilidades del OWASP API Security Top 10 (especialmente los fallos de autorización BOLA/BFLA, que dominan los incidentes reales), y automatizar la validación de contrato y el fuzzing en el pipeline. Las APIs son hoy la principal superficie de ataque de las aplicaciones; asegurarlas "por diseño" y con tests automatizados es clave.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | OWASP API Security Top 10 (2023) | Taxonomía específica de APIs |
| 2 | BOLA (API1) y BFLA (API5) | Los fallos de autorización dominan los incidentes |
| 3 | Contrato OpenAPI como fuente de verdad | Diseñar seguridad, no parchearla |
| 4 | Validación de esquema y entrada | Rechazar lo que no cumple el contrato |
| 5 | Autenticación y gestión de tokens | JWT, scopes, expiración |
| 6 | Rate limiting y consumo de recursos | API4: abuso y DoS |
| 7 | Fuzzing y testing de contrato en CI | Automatizar la verificación |
Una API segura comienza definiendo activos, consumidores, operaciones y propiedades de autorización. OpenAPI puede especificar rutas, esquemas y mecanismos de autenticación, pero no demuestra que el usuario A deba leer el pedido 42. Esa relación pertenece a la lógica de negocio y debe expresarse mediante requisitos, decisiones centralizadas y pruebas negativas.
El contrato permite linting, generación de casos y detección de cambios incompatibles. Los esquemas restringen forma, tamaño y tipo; las validaciones semánticas comprueban reglas como fechas o transiciones. En el servicio, autenticación establece una identidad y autorización decide cada objeto, campo y función. Un gateway puede verificar token y cuota, pero no conoce por sí solo todas las relaciones del dominio.
La suite combina casos válidos con abuso: identificadores de otro usuario, rol insuficiente, campos adicionales, listas masivas, reintentos, estados inválidos y funciones administrativas. Para BOLA se crean dos identidades y objetos diferenciados; se cambia solo el identificador y se exige una denegación sin filtrar existencia. Para consumo de recursos se prueba paginación, límites, coste y cancelación, no solo peticiones por segundo.
El fuzzing guiado por esquema explora combinaciones que el equipo no escribió, pero su calidad depende del contrato y del oráculo. Una respuesta 500 es un indicio; se investiga el efecto y la reproducibilidad. En APIs GraphQL, gRPC y asíncronas cambian las superficies, aunque permanecen las preguntas de identidad, límites y validación.
Una política de versión protege consumidores, pero mantener una versión vulnerable indefinidamente tampoco es seguro. Se identifican clientes, se publica deprecación, se mide uso y se retira con plan. La telemetría conserva actor, operación, objeto lógico, decisión y correlación sin registrar tokens ni datos sensibles completos.
La UI oculta «exportar todos» a usuarios normales, pero la API acepta la operación si se conoce la ruta. El contrato documenta el endpoint sin su requisito de rol y las pruebas solo usan administrador. Se agrega una política de autorización en servicio, casos negativos por rol, una regla de revisión para operaciones sensibles y alerta de intentos denegados. Ocultar un botón era experiencia de usuario, no control de acceso.
| Término | Definición útil |
|---|---|
| Contrato | Descripción interoperable de operaciones y mensajes; no prueba autorización. |
| BOLA | Acceso indebido a objetos por faltar una comprobación contextual. |
| Mass assignment | Modificación de campos internos al enlazar entrada sin lista permitida. |
| Rate limit | Restricción de frecuencia; debe considerar identidad, operación y coste. |
| Prueba negativa | Caso que exige rechazar una acción inválida o no autorizada. |
El alumno domina la clase si transforma propiedades de negocio en contrato, implementación y pruebas negativas; diferencia gateway de autorización de dominio; controla recursos; y conserva evidencia operativa sin filtrar secretos.
pip install schemathesis
# Fuzzing dirigido por el contrato OpenAPI:
schemathesis run http://localhost:8000/openapi.json --checks all
Nota ética: crAPI, VAmPI y similares son APIs deliberadamente vulnerables para practicar. No pruebes BOLA/BFLA ni fuzzing contra APIs de terceros sin autorización explícita.
GET /users/{idA}/profile), luego cambia el id por el de otro usuario. Si respondes con datos ajenos, es BOLA. Documenta la causa: falta de check de propiedad.POST /admin/...). Si funciona, es BFLA.securitySchemes (bearer JWT), scopes por endpoint, esquemas de request con required y additionalProperties: false para evitar mass assignment.spectral lint openapi.yaml
schemathesis run http://localhost:8000/openapi.json --checks all --hypothesis-max-examples 200
Revisa violaciones de esquema, 500s y respuestas fuera de contrato. 7. Escaneo dirigido con ZAP. Importa el OpenAPI en ZAP y lanza un active scan enfocado en los endpoints reales. 8. Integra en CI. Añade jobs de lint del contrato + Schemathesis contra una instancia efímera; falla el build ante violaciones de contrato o errores de servidor.
additionalProperties: false y allowlist.Asegura una API de extremo a extremo con controles y verificación automatizada.
Criterio de aceptación: (a) el contrato OpenAPI define autenticación, autorización por endpoint y validación estricta de esquema; (b) los fallos BOLA y BFLA de la API de práctica están corregidos y verificados; (c) el pipeline lintea el contrato y ejecuta fuzzing basado en contrato que pasa; y (d) hay rate limiting activo demostrable.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Cambiar un ID en la URL devuelve datos de otro usuario | BOLA: falta autorización por objeto. Verifica propiedad en cada request. |
| Un usuario normal accede a endpoints de admin | BFLA: control por función ausente. Deny-by-default y checks por rol. |
El cliente envía is_admin: true y funciona |
Mass assignment. Usa allowlist de campos y additionalProperties: false. |
| La API devuelve todo el objeto de usuario | Exposición excesiva de datos. Serializa solo los campos necesarios. |
| Fuerza bruta al login sin límite | Falta rate limiting (API4). Añade límites por IP/usuario y backoff. |
❓ ¿Por qué el Top 10 de APIs es distinto del web clásico? Las APIs exponen lógica y objetos directamente y suelen delegar la UI al cliente; por eso los fallos de autorización (BOLA/BFLA) y de consumo de recursos dominan, más que XSS clásico.
❓ ¿Un WAF me protege de BOLA? Casi nunca. BOLA es un fallo de lógica de autorización: el request es "válido" técnicamente. Se corrige en el código verificando la propiedad del objeto, no con firmas genéricas.
❓ ¿El contrato OpenAPI mejora la seguridad o solo la documentación? Ambas. Como fuente de verdad permite validar entradas, generar tests/fuzzing y detectar respuestas fuera de contrato automáticamente.
❓ ¿Fuzzing de contrato reemplaza al pentest de API? No. Encuentra desviaciones de esquema y errores, pero la lógica de autorización y las cadenas de abuso siguen necesitando análisis manual.
Clase 246 — Supply chain security: SBOM y SLSA