IDOR

IDOR (Insecure Direct Object Reference, referencia directa insegura a objetos) es una vulnerabilidad en la que la aplicación usa un identificador de la petición, como /api/orders/1043, para obtener un registro, pero nunca comprueba que el usuario con sesión iniciada tenga permiso para acceder a ese registro. Cambias el ID a 1044 y obtienes el pedido de otra persona. Se incluye en A01 Broken Access Control del OWASP Top 10 2021, y el OWASP API Security Top 10 llama al mismo problema Broken Object Level Authorization (BOLA).

Ejemplo

Alice ha iniciado sesión y ve su pedido:

GET /api/orders/1043
Authorization: Bearer <alice-token>

Cambia el número:

GET /api/orders/1044
Authorization: Bearer <alice-token>

Si la respuesta es 200 con la dirección y los artículos de Bob, el endpoint autentica al usuario pero no autoriza el acceso a ese objeto concreto. Los UUID difíciles de adivinar complican las conjeturas, pero no corrigen el fallo; los ID se filtran a través de URLs, logs y enlaces compartidos.

Qué comprueba un tester

Crea dos usuarios de prueba, cada uno con sus propios datos, y usa las credenciales del usuario A contra los objetos del usuario B en todos los endpoints y métodos: lectura, actualización, borrado y rutas anidadas como /users/{id}/invoices. Es fácil de automatizar. En Playwright:

import { test, expect, request } from '@playwright/test';

test("Alice cannot read Bob's order", async () => {
  const alice = await request.newContext({
    baseURL: process.env.API_URL,
    extraHTTPHeaders: { Authorization: `Bearer ${process.env.ALICE_TOKEN}` },
  });
  const res = await alice.get(`/api/orders/${process.env.BOB_ORDER_ID}`);
  expect([403, 404]).toContain(res.status());
  await alice.dispose();
});

Tanto 403 como 404 son aceptables; muchas APIs devuelven 404 para ni siquiera confirmar que el registro existe. Comprueba también:

• Los ID en los cuerpos de las peticiones y en los query strings, no solo en la ruta.
• Las operaciones de escritura, donde un IDOR permite a un usuario cambiar o borrar datos.
• Los endpoints masivos y de exportación que aceptan listas de ID.
• Las fronteras entre tenants en sistemas multi-tenant.

Por qué se cuela

Las pruebas funcionales suelen iniciar sesión con un usuario y usar sus propios datos, así que la comprobación de autorización nunca se ejercita. Los IDOR se encuentran preguntando “¿y si este ID perteneciera a otra persona?” en cada endpoint. Ejecuta estas pruebas solo contra sistemas que tengas autorización para probar.