# OWASP API Security Top 10: riesgos y evaluación de APIs

Qué cubre OWASP API Security Top 10 2023 y cómo usarlo para definir una evaluación autorizada de seguridad de APIs.

## Qué es OWASP API Security Top 10

Es una clasificación de riesgos frecuentes de seguridad en APIs. La edición 2023 ayuda a orientar una revisión; no sustituye el inventario, las pruebas ni el análisis de impacto de cada aplicación.

## Los diez riesgos de la edición 2023

API1: autorización de objetos. API2: autenticación. API3: autorización de propiedades. API4: consumo de recursos. API5: autorización de funciones. API6: acceso a flujos de negocio sensibles. API7: solicitudes del servidor a destinos no previstos (SSRF). API8: configuración. API9: inventario. API10: consumo inseguro de otras APIs.

## Cómo preparar una evaluación útil

Entrega el inventario de endpoints, los roles permitidos y un entorno de prueba cuando sea posible. Define qué operaciones pueden ejecutarse, con qué cuentas y sobre qué datos. Incluye ejemplos de un flujo permitido y otro que debería rechazarse; esto ayuda a distinguir un comportamiento esperado de una vulnerabilidad.

## Qué pedir en el reporte

Cada hallazgo debe identificar el activo, el comportamiento observado, los permisos usados, el impacto y la evidencia suficiente para reproducirlo dentro del alcance autorizado. Pide una recomendación concreta y una forma de comprobar que la corrección funciona. Una referencia a OWASP por sí sola no demuestra que exista una vulnerabilidad.

## Autorización de objetos, propiedades y funciones

Una revisión de API debe distinguir tres preguntas: si la persona puede consultar ese registro, si puede ver o modificar cada campo y si puede ejecutar la función solicitada. Para preparar la evaluación, construye una matriz con roles, operaciones y resultados esperados. Utiliza cuentas y datos de prueba que permitan reconocer una autorización correcta sin exponer información de clientes. Por ejemplo, un usuario de soporte puede necesitar leer un ticket, pero no administrar cuentas ni cambiar su propietario. La prueba debe contrastar el comportamiento permitido con el que tendría que rechazarse.

## Inventario y versiones que siguen expuestas

El inventario debe reunir hosts, versiones, rutas, propietarios y entornos incluidos. Una API antigua puede seguir atendiendo solicitudes aunque ya no aparezca en la documentación del producto. También pueden existir integraciones utilizadas solo por una aplicación móvil o un proceso interno. Antes de evaluar, aclara qué rutas están en producción, cuáles se retirarán y cuáles pertenecen a terceros. Documenta los puntos donde no hay información suficiente. Un endpoint que no se revisó no debe aparecer en el informe como seguro ni como inexistente.

## Consumo de recursos y flujos sensibles

Algunas operaciones tienen un costo desproporcionado: generar un archivo, procesar imágenes o solicitar un servicio externo. La revisión necesita conocer límites previstos y efectos sobre disponibilidad o gasto. No hace falta someter producción a una prueba destructiva para plantear esa pregunta. Se puede comenzar con configuración, registros y escenarios controlados dentro del alcance. Los procesos de negocio también necesitan reglas frente al uso automatizado. El equipo debe definir qué comportamiento constituye abuso y qué usuarios legítimos podrían verse afectados por una restricción demasiado amplia.

## Dependencias externas y configuración

Cuando una API utiliza otra, los datos recibidos siguen necesitando validación. El diseño debe describir respuestas inválidas, tiempos de espera y fallos parciales. En la preparación de una evaluación conviene incluir integraciones de pago, notificación o consulta que puedan cambiar el comportamiento de la aplicación. También se revisa qué información aparece en errores y qué configuraciones corresponden a cada entorno. Las comprobaciones activas deben respetar las condiciones del proveedor externo; tener autorización sobre una aplicación propia no extiende automáticamente el permiso a toda su cadena de servicios.

## Cómo convertir el reporte en trabajo de ingeniería

Solicita que cada hallazgo identifique método, ruta, rol utilizado, condición observada y alcance del impacto. La evidencia debe ser suficiente para reproducir el problema de forma autorizada y sin incorporar secretos innecesarios. Una recomendación como mejorar la seguridad no permite actuar: el responsable necesita saber qué validación falta y dónde aplicarla. Después de corregir, se comprueba tanto el rechazo del caso indebido como la continuidad de la operación permitida. Conserva las limitaciones de cobertura para que la siguiente revisión pueda completar lo que no se evaluó.

## Preguntas para preparar el alcance

Antes de solicitar una evaluación, identifica al propietario de cada API, los roles disponibles y los datos que pueden usarse en pruebas. Aclara si se permite crear registros, ejecutar operaciones de escritura o activar integraciones. Define un contacto operativo y condiciones de detención. Si no puedes facilitar cuentas con distintos permisos, el reporte debe reflejar esa limitación. La clasificación OWASP organiza preguntas útiles, pero la cobertura concreta se acuerda por aplicación. No equivale a una certificación ni demuestra que una herramienta haya comprobado todos los riesgos listados.

Fuente: https://api-security.owasp.org/editions/2023/en/0x11-t10/