IDOR

IDOR (Insecure Direct Object Reference, unsichere direkte Objektreferenz) ist eine Schwachstelle, bei der die Anwendung einen Identifier aus dem Request, etwa /api/orders/1043, nutzt, um einen Datensatz zu laden, aber nie prüft, ob der angemeldete Nutzer auf diesen Datensatz zugreifen darf. Ändern Sie die ID auf 1044, und Sie erhalten die Bestellung eines anderen. In den OWASP Top 10 2021 fällt das unter A01 Broken Access Control, und die OWASP API Security Top 10 nennen dasselbe Problem Broken Object Level Authorization (BOLA).

Beispiel

Alice ist angemeldet und sieht ihre Bestellung:

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

Sie ändert die Nummer:

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

Kommt 200 mit Bobs Adresse und Artikeln zurück, authentifiziert der Endpoint zwar den Nutzer, autorisiert aber nicht den Zugriff auf das konkrete Objekt. Schwer zu erratende UUIDs erschweren das Raten, beheben die Lücke aber nicht; IDs sickern über URLs, Logs und geteilte Links durch.

Was ein Tester prüft

Legen Sie zwei Testnutzer mit jeweils eigenen Daten an und verwenden Sie dann die Zugangsdaten von Nutzer A gegen die Objekte von Nutzer B – auf jedem Endpoint und mit jeder Methode: Lesen, Ändern, Löschen und verschachtelte Routen wie /users/{id}/invoices. Das lässt sich leicht automatisieren. In 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();
});

Sowohl 403 als auch 404 sind akzeptabel; viele APIs liefern 404, um nicht einmal zu bestätigen, dass der Datensatz existiert. Prüfen Sie außerdem:

• IDs in Request-Bodies und Query-Strings, nicht nur im Pfad.
• Schreiboperationen, bei denen ein IDOR es einem Nutzer erlaubt, Daten zu ändern oder zu löschen.
• Bulk- und Export-Endpoints, die Listen von IDs akzeptieren.
• Mandantengrenzen in mandantenfähigen Systemen.

Warum es durchrutscht

Funktionale Tests melden sich meist als ein Nutzer an und verwenden dessen eigene Daten, sodass die Autorisierungsprüfung nie durchlaufen wird. IDOR findet man, indem man sich bei jedem Endpoint fragt: „Was, wenn diese ID jemand anderem gehört?“ Führen Sie solche Tests nur gegen Systeme aus, für die Sie eine Testberechtigung haben.