Plantilla de Revisión de Seguridad de API (OWASP)

Visión General

Una revisión de seguridad de API es una auditoría estructurada de cómo una API gestiona autenticación, autorización, entrada de datos y abuso — antes y después de salir a producción. Un único check de propietario que falte o una entrada sin validar puede exponer datos de clientes o permitir el robo de cuentas, y esos son justo los huecos que los escáneres automáticos siguen pasando por alto. Esta plantilla es un checklist rellenable: cópialo en un ticket, complétalo por API y guarda la revisión terminada como evidencia de auditoría. Cada sección mapea al OWASP API Security Top 10 (2023), así que los fallos conocidos quedan cubiertos por construcción.

Cuándo Usar

• Antes de lanzar a producción una API pública o para socios.
• Durante una auditoría de seguridad trimestral de APIs existentes.
• Después de un incidente de seguridad, una actualización mayor de dependencias o un cambio de infraestructura.
• Al incorporar un servicio nuevo que consume o expone APIs.
• Cuando un marco de cumplimiento (SOC 2, ISO 27001) exige revisiones de seguridad documentadas.

Este checklist no sustituye a un penetration test — detecta configuraciones incorrectas y omisiones conocidas, no vulnerabilidades nuevas. Para un recorrido control por control, consulta la guía de checklist de seguridad de API.

Solución

# Revisión de Seguridad de API: `<Nombre de la API>`

## 1. Metadatos

| Campo | Valor |
|-------|-------|
| Nombre de la API | `nombre` |
| Versión | `v1.0.0` |
| Tipo de API | `REST / GraphQL / gRPC / WebSocket` |
| Exposición | `Interna / Socio / Pública` |
| Tipo de Autenticación | `OAuth2 / API Key / mTLS / Ninguna` |
| Responsable de Seguridad | `@nombre` |
| Fecha de Revisión | `YYYY-MM-DD` |

## 2. Autenticación

- [ ] Todos los endpoints requieren autenticación, excepto los documentados como públicos
- [ ] Los tokens OAuth2/OIDC llegan por `Authorization: Bearer`; se validan state, PKCE y la lista permitida de redirect URIs
- [ ] Las API keys se envían en el header `X-Api-Key` — nunca en query params
- [ ] Las API keys se rotan cada 90 días y se guardan en un gestor de secretos
- [ ] Los access tokens expiran en menos de 1 hora; los refresh tokens rotan en cada uso y son revocables
- [ ] El JWT se valida: firma, expiración, issuer, audience
- [ ] MFA obligatorio para operaciones de administración y otras sensibles
- [ ] mTLS obligatorio para comunicación servicio-a-servicio en producción
- [ ] Las credenciales nunca se loguean, se devuelven en errores ni van en URLs

## 3. Autorización

- [ ] El control de acceso verifica al propietario del recurso, no solo el estado de autenticación (BOLA/IDOR)
- [ ] Control de acceso horizontal: el usuario A no puede leer datos de `/users/{id}` del usuario B
- [ ] Control de acceso vertical: los endpoints de administración rechazan tokens sin rol admin
- [ ] Los claims de rol/permiso se validan en servidor — nunca se confía en el cliente
- [ ] Los endpoints de lista y búsqueda limitan resultados al ámbito del llamante actual
- [ ] Los sub-recursos heredan los permisos del padre (p.ej., `/orders/{id}/items`)
- [ ] Cada acción sensible queda auditada (creación, borrado, acceso masivo a datos)
- [ ] No hay bypass de autenticación por path traversal o HTTP method override

## 4. Validación de Entrada

- [ ] Todas las entradas se validan contra un schema estricto (OpenAPI, JSON Schema)
- [ ] Los payloads con tipos incorrectos se rechazan — no se convierten silenciosamente
- [ ] Tamaño máximo de payload en el gateway (p.ej., 1 MB); límites de string, array y profundidad de anidado
- [ ] El header Content-Type se valida contra el cuerpo real
- [ ] Solo consultas parametrizadas u ORM — nada de concatenar strings en SQL
- [ ] Los parámetros de ruta se validan contra patrones esperados (UUID, slug, numérico)
- [ ] Los uploads se limitan a una lista permitida de nombres y tipos MIME, con análisis de malware
- [ ] SSRF: las requests salientes se validan contra una lista permitida de dominios

## 5. Rate Limiting y Prevención de Abuso

| Tipo de Cliente | Límite | Ventana | Al Exceder |
|-----------------|--------|---------|------------|
| No autenticado | 60 req/min | 1 minuto | 429 + `Retry-After` |
| Autenticado | 1.000 req/min | 1 minuto | 429 + `Retry-After` |
| Premium | 10.000 req/min | 1 minuto | Throttling escalonado |

- [ ] Rate limits por ID de consumidor y por endpoint — no globales, no solo por IP
- [ ] Headers de rate limit en todas las respuestas (`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`)
- [ ] DDoS volumétrico gestionado en la capa CDN/WAF
- [ ] Bloqueo de cuenta tras N intentos de autenticación fallidos

## 6. Gestión de Secretos

- [ ] No hay credenciales, tokens ni claves de firma en el código fuente
- [ ] Los secretos se inyectan como variables de entorno o vía gestor de secretos (Vault, AWS Secrets Manager)
- [ ] Las claves de firma de JWT rotan periódicamente con solapamiento para tokens antiguos
- [ ] Los logs no contienen tokens, contraseñas ni números de tarjeta

## 7. Protección de Datos y Salida

- [ ] No hay datos sensibles en las respuestas (contraseñas, tokens, PII innecesaria)
- [ ] TLS 1.2+ en tránsito con HSTS; AES-256 en reposo
- [ ] Los campos de respuesta se filtran por rol del llamante — sin mass assignment de lectura
- [ ] CORS con lista permitida explícita — nada de wildcard `*` con credenciales
- [ ] `Cache-Control: no-store` en respuestas con datos sensibles
- [ ] Headers de seguridad: `X-Content-Type-Options: nosniff`, CSP `frame-ancestors` donde se sirva HTML
- [ ] PII enmascarada o tokenizada en logs

## 8. Manejo de Errores y Logging

- [ ] Las respuestas de error no filtran stack traces, SQL ni rutas internas
- [ ] Los fallos de autenticación devuelven mensajes genéricos (sin enumeración de usuarios)
- [ ] Cada request loguea: timestamp, ID de cliente, endpoint, método, código de estado, latencia
- [ ] Los intentos de autenticación fallidos se loguean con IP y timestamp
- [ ] Los logs se reenvían a un SIEM con protección contra manipulación; retención ≥ 90 días
- [ ] Monitorización de anomalías (picos de tráfico, patrones de scraping)

## 9. Cobertura OWASP API Security Top 10 (2023)

| Riesgo | Check | Estado |
|--------|-------|--------|
| API1 Broken Object Level Authorization | Check de propietario en cada endpoint de objeto | Aprobado / Falla |
| API2 Broken Authentication | Validación de tokens, protección contra fuerza bruta | Aprobado / Falla |
| API3 Broken Object Property Level Authorization | Filtrado de campos de respuesta, sin mass assignment | Aprobado / Falla |
| API4 Unrestricted Resource Consumption | Rate limits, límites de payload, timeouts | Aprobado / Falla |
| API5 Broken Function Level Authorization | Funciones admin rechazan llamantes sin rol | Aprobado / Falla |
| API6 Unrestricted Access to Sensitive Business Flows | Anti-automatización en flujos de registro/compra | Aprobado / Falla |
| API7 Server Side Request Forgery | Lista permitida de URLs salientes, metadata de cloud bloqueada | Aprobado / Falla |
| API8 Security Misconfiguration | Sin credenciales por defecto, TLS endurecido | Aprobado / Falla |
| API9 Improper Inventory Management | Versiones deprecadas retiradas, endpoints no documentados auditados | Aprobado / Falla |
| API10 Unsafe Consumption of APIs | Respuestas de terceros validadas, TLS ascendente verificado | Aprobado / Falla |

## 10. Hallazgos y Cierre

| # | Hallazgo | Severidad | Responsable | Fecha límite | Estado |
|---|----------|-----------|-------------|--------------|--------|
| 1 | | | | | |

| Campo | Valor |
|-------|-------|
| Revisor | `@nombre` |
| Segundo revisor | `@nombre` (obligatorio en APIs públicas) |
| Resultado | `Aprobado / Aprobado con excepciones / Bloqueado` |
| Próxima revisión | `YYYY-MM-DD` |

Cómo Ejecutar la Revisión

1. Delimita la API. Lista sus endpoints desde la spec OpenAPI o la config del gateway y marca cada uno como público, de socio o interno — la exposición decide la profundidad de cada sección.
2. Rellena el checklist. Trabájalo por API o por grupo de endpoints. Una casilla sin marcar no es un fallo, es un riesgo documentado — cada una se convierte en un ticket de remediación.
3. Puntúa los hallazgos con la tabla de severidad de abajo para que las correcciones caigan en el orden correcto.
4. Remedia y re-verifica. Reejecuta las secciones fallidas cuando salgan los arreglos, y repite el checklist completo en los 30 días siguientes a cualquier incidente de seguridad.
5. Archiva la revisión completada con fecha y revisor. Los auditores piden evidencia, no intenciones.

Para un alcance más estrecho — un PR que toca una ruta de autenticación — el checklist de revisión de seguridad para PRs encaja mejor que esta pasada completa.

Puntuación de Hallazgos

Cada casilla sin marcar es un riesgo que el equipo decide aceptar o corregir. Triage sugerido:

Severidad	Ejemplos	Acción
Bloqueante	Bypass de autenticación, BOLA sobre datos de producción, inyección, secretos en código o logs	Corregir antes del release
Alta	Sin rate limits en endpoints públicos, validación de tokens débil, TLS ausente	Corregir dentro del sprint
Media	Headers de seguridad ausentes, errores verbosos, endpoints no documentados	Planificar y hacer seguimiento
Baja	Huecos de documentación, hardening no crítico	Backlog con responsable

Los bloqueantes y altos sin resolver necesitan una excepción por escrito — responsable, riesgo residual y fecha límite. Hazles seguimiento igual que a los CVE; un proceso de gestión de vulnerabilidades evita que los riesgos aceptados se conviertan en riesgos olvidados.

Explicación

El checklist está organizado como defensa en profundidad: una request atraviesa el CDN/WAF (ataques volumétricos), el gateway (rate limits, autenticación), el servicio (autorización a nivel de objeto), la validación de entrada y por último la capa de datos (cifrado, salida filtrada). La mayoría de brechas en APIs vienen de una única capa saltada — normalmente la autorización, porque los equipos verifican quién llama pero nunca si ese llamante puede ver este objeto. Eso es BOLA, y está en API1 del OWASP API Top 10 por algo.

Variantes

Contexto	Enfoque	Notas
APIs internas	Revisión ligera, foco en auth y secretos	Omite checks de DDoS/CORS tras una VPN — pero interno no significa confiable
APIs de socio	Contrato + revisión	Exige cuestionario de seguridad; verifica firma HMAC de requests, timestamp y protección anti-replay
APIs SaaS públicas	Revisión completa + pentest	Pentest externo al menos anual
GraphQL	Añade checks de profundidad/complejidad	Limita el anidado y el coste computacional de las queries
gRPC	Verifica certificados mTLS	Valida SANs y expiración de certificados
WebSocket	Valida el origen, rate-limita frames	Previene DoS por inundación de frames

Lo que Funciona

1. Ejecuta la revisión en cada cambio que toque autenticación, autorización o manejo de entradas — no solo antes de releases grandes.
2. Automatiza lo automatizable: escaneo de secretos, SAST, checks de dependencias y validación de schema OpenAPI en CI.
3. Exige dos revisores en APIs públicas — uno de seguridad y uno de ingeniería.
4. Documenta cada excepción con riesgo residual y plan de mitigación, o se convierte en deuda invisible.
5. Rota los secretos inmediatamente tras un incidente o una rotación relevante de personal.
6. Consigue un pentest externo al menos una vez al año para APIs públicas.

Errores Comunes

1. Asumir que las APIs internas son seguras por estar detrás de un firewall — la red interna no es un perímetro.
2. Validar entradas solo en el frontend y confiar en lo que mande el cliente de la API.
3. Verificar autenticación pero saltarse la autorización a nivel de objeto — eso es BOLA, el riesgo de API más explotado.
4. Validar firma y expiración del JWT pero olvidar el claim audience.
5. Limitar el rate solo por IP ignorando los IDs de consumidor autenticado — un usuario puede alquilar mil IPs.
6. Loguear el cuerpo completo de las requests, que captura silenciosamente tokens y PII.

Troubleshooting

• Bypass de autenticación en tests: los usuarios de test y staging no deben llegar a endpoints de producción — mantén credenciales y redes separadas por entorno.
• Falsos positivos del escáner: ajusta las reglas a tu perfil de riesgo y distingue vulnerabilidades alcanzables de hallazgos teóricos antes de abrir tickets.
• Aparecen secretos en los logs: enmascara tokens, contraseñas y claves en el destino de logs, y audita los sinks existentes por valores filtrados.
• Los headers de seguridad rompen clientes: despliega CSP y headers estrictos primero en modo report-only y endurece según las violaciones reales.
• Las revisiones quedan obsoletas: asigna un responsable de seguridad con nombre y una cadencia de revisión por API; un checklist completado que nadie reejecuta caduca en un trimestre.

Véase También

• Repositorio complementario: la plantilla rellenable más un ejemplo de revisión completada como archivos markdown independientes.
• OWASP API Security Top 10 (2023): la lista de riesgos canónica a la que mapea la sección 9.
• OWASP REST Security Cheat Sheet: guía control por control para cada ítem del checklist.
• RFC 7519 — JSON Web Token: lo que la validación de iss, aud y exp exige realmente.
• OWASP ZAP: herramienta DAST gratuita para la mitad runtime de la revisión.
• Checklist de remediación OWASP Top 10: el paso siguiente cuando la revisión encuentra fallos.