Auditoría de seguridad de API: qué probar antes de exponerla

Por Carlos Isidoro De Ayala Diaz ·

Auditoría de seguridad de API: inventario, autorización, OAuth, lógica de negocio, límites y evidencias para proteger integraciones entre empresas B2B.

Empieza por el inventario, los roles y los datos que la API realmente expone

Una auditoría de API no debería comenzar lanzando peticiones contra una URL sin contexto. Primero se identifican dominios, versiones, endpoints, métodos, eventos, cargas de archivos y conexiones con terceros. La especificación OpenAPI ayuda, pero se contrasta con rutas publicadas, configuración del gateway y registros autorizados: puede haber versiones antiguas, endpoints administrativos o funciones móviles que no aparecen en la documentación principal. Cada elemento se vincula con su propietario y con el entorno permitido para las pruebas.

Después se construye una matriz de identidades y operaciones. Para cada rol se documenta qué objetos puede consultar, crear, modificar o borrar, y en nombre de qué empresa o usuario. Tener un token válido solo acredita una identidad; no demuestra que pueda acceder al identificador que llega en la ruta, cambiar propiedades sensibles o invocar una función administrativa. Se preparan al menos dos usuarios de prueba con datos sintéticos separados para detectar cruces horizontales y un perfil con privilegios distintos para revisar escaladas verticales.

El alcance también debe indicar sistemas excluidos, límites de automatización, ventanas, contactos y condiciones de parada. Una API puede activar facturación, comunicaciones, pedidos o procesos físicos aunque la respuesta sea solo JSON. Las pruebas no usan datos reales de clientes cuando una muestra controlada permite comprobar el mismo control. NIST SP 800-228 recomienda abordar el riesgo y los controles a lo largo del ciclo de vida y distinguir medidas previas a la ejecución de las protecciones aplicadas durante el funcionamiento.

Comprueba autenticación, autorización y ciclo de vida de los tokens por separado

La autenticación responde quién realiza la petición; la autorización decide si esa identidad puede ejecutar esa operación sobre ese objeto y esas propiedades. La auditoría verifica ambas capas en cada ruta relevante. Se prueban identificadores pertenecientes a otro usuario o empresa, cambios de rol, campos que el cliente no debería controlar y funciones que solo aparecen en interfaces internas. OWASP sitúa entre los riesgos principales la autorización rota por objeto, por propiedad y por función porque un control global no cubre necesariamente cada decisión de negocio.

Si el sistema utiliza OAuth, se revisan los flujos realmente desplegados, los URI de redirección, PKCE cuando corresponde, audiencia, alcance, caducidad y tratamiento de tokens de actualización. RFC 9700 recomienda coincidencia exacta de redirecciones, desaconseja el flujo implícito en los escenarios descritos, limita privilegios y propone rotación o vinculación de los refresh tokens para clientes públicos. Estas prácticas no se convierten en una lista ciega: se contrastan con el tipo de cliente, el servidor de autorización y los recursos protegidos del proyecto.

Las claves de API y credenciales de servicio también requieren propietario, permisos mínimos, rotación y revocación. No deben aparecer en repositorios, aplicaciones cliente, URL, capturas o registros. Las cuentas creadas para la auditoría se entregan por el canal acordado, nunca mediante el formulario comercial, y se deshabilitan o cambian al terminar. La prueba incluye cierre de sesión, revocación y comportamiento ante tokens caducados para comprobar que la aplicación y la API responden de forma coherente.

Prueba la lógica de negocio y el consumo de recursos sin convertir el ensayo en un ataque de disponibilidad

Las vulnerabilidades de una API no siempre dependen de una entrada con formato extraño. Un flujo puede permitir reservar repetidamente un recurso escaso, saltar un orden de aprobación, reutilizar un cupón o consultar datos por combinaciones que la interfaz no ofrece. La revisión modela operaciones completas y sus estados: qué debe ocurrir antes, quién puede repetirlas y qué condiciones impiden avanzar. También comprueba asignación masiva de propiedades, filtros, paginación, exportaciones y respuestas que devuelven más campos de los necesarios.

Los límites se validan con precaución. Se revisan tamaños, frecuencia, número de elementos, coste de consultas y consumo de servicios externos, pero no se ejecuta una saturación deliberada sin autorización específica, entorno adecuado y plan de parada. OWASP incluye el consumo de recursos sin restricciones y el acceso sin control a flujos sensibles entre sus riesgos de API. El objetivo empresarial es demostrar si existen límites razonables y alertas, no provocar una caída para probar que una carga ilimitada resulta dañina.

Entradas como URL remotas, archivos, plantillas o consultas complejas necesitan validación, restricciones y tratamiento seguro de errores. Las respuestas no deberían revelar trazas, secretos ni detalles internos innecesarios. Se comprueba también idempotencia en operaciones que pueden reintentarse: una interrupción entre cliente y servidor no debe duplicar un pedido o un cobro. Los registros deben permitir reconstruir la acción con identificadores y resultado, sin almacenar el token completo ni contenido sensible ajeno al diagnóstico.

Entrega evidencias reproducibles y separa la corrección de su comprobación

Cada hallazgo identifica endpoint, rol, precondiciones, petición y respuesta depuradas, resultado esperado, resultado observado e impacto. Las evidencias eliminan tokens y datos personales y utilizan referencias que el equipo de desarrollo pueda reproducir. La prioridad considera exposición, privilegios necesarios, alcance entre clientes, efecto sobre el proceso y controles compensatorios. Una puntuación aislada no sustituye esta explicación ni convierte automáticamente un comportamiento en riesgo crítico.

El informe relaciona cada recomendación con el punto donde debe aplicarse: código, gateway, proveedor de identidad, configuración o proceso. También registra rutas revisadas, límites y pruebas no realizadas para que dirección entienda qué cubre la conclusión. Corregir un ejemplo no garantiza que el mismo patrón haya desaparecido de todos los endpoints. La segunda comprobación se define aparte con sus hallazgos, versión, entorno y fecha; no equivale por defecto a repetir toda la auditoría.

Élite Solutions Tech puede definir desde Murcia una auditoría autorizada para APIs empresariales con cobertura regional o nacional. Las certificaciones OSCP y OSEP aportan metodología ofensiva para formular y comprobar hipótesis, mientras que el registro en el Catálogo de Empresas y Soluciones de Ciberseguridad de INCIBE ofrece una referencia pública de la empresa. La propuesta concreta endpoints, roles, profundidad manual, exclusiones, entregables, actuaciones de corrección y si incluye una segunda comprobación.