Pruebas de autorización en APIs

Una sesión válida prueba autenticación. Después la API decide si esa identidad puede usar una función, operar sobre un objeto y leer o escribir sus propiedades. Si existen tenants, también hay que comprobar esa frontera. Durante una auditoría, la referencia es el comportamiento esperado para cada identidad y recurso, no el código HTTP aislado.

Preparar cuentas y objetos

Crea o identifica dos usuarios normales, user_a y user_b, con objetos propios que puedas reconocer. Añade un administrador y un segundo tenant solo si la aplicación tiene esos roles o límites. Apunta los IDs y la propiedad real de cada objeto desde una vista autorizada. Usa datos de prueba para que una escritura pueda verificarse y revertirse.

Esta matriz es una hipótesis de permisos para un target de ejemplo. Documenta excepciones reales: una factura compartida o un rol de soporte pueden hacer legítimo un acceso cruzado. Para multi-tenant prepara además tenant_a/user_a y tenant_b/user_c. Dos usuarios del mismo tenant no cubren esa frontera.

Replay mínimo

Captura en Burp Suite una petición legítima de user_a y conserva una copia intacta. Estabiliza método, path, body y headers relevantes. Cambia una variable cada vez y registra la pareja baseline/variante.

GET /api/invoices/1042 HTTP/1.1
Host: example.test
Authorization: Bearer <USER_A_TOKEN>
Accept: application/json

Comprueba primero que 1042 pertenece a A. Repite con el token de B. Después prueba el token de A contra 2048, propiedad de B. Si ambas variantes se rechazan, no extrapoles a operaciones de escritura: ejecuta una prueba de edición separada sobre un campo inocuo y verifica el objeto con su propietario. Un 200 puede devolver un mensaje genérico sin efecto, y un 404 puede ser la forma prevista de ocultar un objeto ajeno.

Guarda en la matriz la identidad usada, el recurso, la operación, el resultado esperado y el observado. Si una sesión deja de funcionar, renueva el baseline antes de interpretar las variantes. Un token caducado vuelve inútil la comparación.

Objetos: lectura y escritura

Busca IDs en paths, query strings, bodies, respuestas previas y relaciones anidadas. Un UUID difícil de adivinar también necesita autorización cuando puede obtenerse por otra vía. Para un recurso anidado como /accounts/7/invoices/1042, comprueba tanto la cuenta como la factura. Cambiar solo el ID hijo puede revelar qué nivel valida el backend.

Una escritura controlada puede usar una marca reconocible:

PATCH /api/invoices/1042 HTTP/1.1
Host: example.test
Authorization: Bearer <USER_B_TOKEN>
Content-Type: application/json

{"note":"auth-check-01"}

Si B no debería editar la factura de A, vuelve a leerla con A. Registra el valor anterior y posterior. En endpoints batch, prueba que cada elemento del lote aplique su propia decisión de acceso. En GraphQL, la misma comprobación puede recaer sobre el id o los argumentos de una query o mutation. La forma del transporte cambia, la propiedad del objeto no.

Funciones y rutas equivalentes

Enumera operaciones sensibles observadas en la UI, documentación o tráfico: POST /users/{id}/disable, DELETE, /admin/..., exportar, aprobar o invitar. Repite una petición válida con un rol inferior. La ausencia de un botón no demuestra que la API rechace la llamada directa.

Si la misma función aparece bajo otra ruta o método documentado, compruébala por separado. No supongas que un 403 en /admin/export protege automáticamente /api/reports/export. Tras una operación asíncrona, observa el job y el recurso final antes de concluir que se ejecutó.

Propiedades devueltas y modificables

La autorización de propiedades tiene dos direcciones. Compara las respuestas de un mismo objeto para roles distintos y señala campos sensibles devueltos a quien no debería verlos. Después, en una actualización permitida del perfil propio, prueba si el backend acepta campos que la UI no expone:

{
  "display_name": "user_a",
  "role": "admin"
}

El hallazgo requiere comprobar el valor persistido o el efecto de privilegio posterior. Un 200 que ignora role no demuestra mass assignment. Prueba también propiedades anidadas cuando el endpoint las acepte y compara la respuesta con una lectura posterior. Usa valores reversibles y evita tocar cuentas reales.

Tenants y validación del finding

Dentro de un tenant, A y B pueden compartir datos por diseño. La prueba entre tenants necesita una identidad y un objeto de cada lado: tenant_a/user_a → tenant_b/invoice. Registra el tenant efectivo de la sesión, del objeto y de cualquier parent ID. Si un token tiene acceso legítimo a ambos tenants, no sirve para probar aislamiento.

La evidencia mínima es: regla esperada, origen del objeto, identidad y rol, request baseline, variante, respuesta y estado posterior. Comprueba caché, jobs, consistencia eventual y cambios hechos por otros procesos cuando el resultado parezca contradictorio. Retira tokens activos del informe. Burp Repeater ayuda a mantener comparables las requests. La interpretación de la política y del efecto sigue siendo manual.

Referencias

• OWASP API1
  — Broken Object Level Authorization
• OWASP API3
  — Broken Object Property Level Authorization
• OWASP API5
  — Broken Function Level Authorization
• OWASP WSTG — Bypassing Authorization Schema