BOLA und IDOR in REST-APIs erkennen und verhindern: Autorisierung richtig testen

Ein Supportmitarbeiter öffnet in einer mobilen Kunden-App eine Rechnung. Die App ruft dafür GET /api/invoices/4711 auf. Ein Entwickler ändert die Zahl in einem Testwerkzeug auf 4712 und erhält eine Rechnung eines anderen Kunden. Die Anmeldung funktioniert, das Zugriffstoken ist gültig, die API liefert trotzdem fremde Daten aus. Genau das ist ein typischer Fall von BOLA beziehungsweise IDOR und einer der folgenreichsten Fehler in REST-APIs.

BOLA steht für „Broken Object Level Authorization“. Gemeint ist eine fehlende oder fehlerhafte Berechtigungsprüfung auf Ebene einzelner Objekte. IDOR, „Insecure Direct Object Reference“, beschreibt den häufigen technischen Auslöser: Eine Anwendung übernimmt eine direkt übergebene Objektkennung, etwa eine Rechnungsnummer, Benutzer-ID oder Dokument-ID, ohne zuverlässig zu prüfen, ob der anfragende Nutzer dieses Objekt lesen oder verändern darf.

Das Risiko betrifft nicht nur klassische Webanwendungen. Besonders häufig sehen wir solche Fehler bei mandantenfähigen SaaS-Anwendungen, Mobile-Backends, Partner-APIs und Schnittstellen für KI-Agenten. Überall dort, wo ein Token vorhanden ist und Objekt-IDs über URLs, Request-Bodies oder GraphQL-Abfragen übergeben werden, muss die Autorisierung konsequent auf dem Server erfolgen.

Infografik zu BOLA und IDOR in REST-APIs erkennen und verhindern: Autorisierung richtig testen (KI-generiert).

Warum BOLA und IDOR so gefährlich sind

Bei vielen Sicherheitslücken muss ein Angreifer zunächst Code ausführen, eine komplizierte Konfiguration umgehen oder Zugangsdaten stehlen. Bei BOLA reicht oft ein gültiger, regulärer Account mit niedrigen Rechten. Das macht die Schwachstelle besonders kritisch: Der Angriff sieht zunächst wie legitime API-Nutzung aus.

Betroffen sein können unter anderem:

• Kundendaten, Rechnungen und Verträge
• Personalakten und interne Tickets
• Dateien, Chatverläufe und Wissensdatenbanken
• Bestellungen, Lieferadressen und Zahlungsinformationen
• Einstellungen anderer Nutzer
• Freigaben, Rollen und Mandantenkonfigurationen
• Datenquellen und Aktionen von KI-Agenten

Der wirtschaftliche Schaden entsteht nicht nur durch Datenabfluss. Ein Nutzer mit unzureichend geprüften Schreibrechten kann Bestellungen stornieren, Bankdaten ändern, Benutzer sperren oder Freigaben manipulieren. Bei KI-Agenten verschärft sich das Risiko, wenn ein Agent auf Basis einer Nutzeranfrage API-Aufrufe ausführt und dabei die Berechtigungen des aufrufenden Nutzers nicht korrekt weitergegeben werden.

BOLA ist keine reine Frage erratbarer IDs. Auch zufällige UUIDs, lange Hashes oder schwer lesbare Schlüssel ersetzen keine Autorisierung. Sie erschweren das Finden fremder Objekte, verhindern den Zugriff aber nicht, sobald eine ID etwa über Links, Logs, Benachrichtigungen, Browser-Verlauf oder eine andere API-Antwort bekannt wird.

BOLA, IDOR und fehlende Funktionsberechtigungen unterscheiden

Für saubere Tests lohnt sich die Abgrenzung. Bei BOLA geht es um ein konkretes Objekt. Ein Nutzer darf beispielsweise seine eigene Rechnung lesen, aber nicht die Rechnung eines anderen Kunden.

Eine fehlende Funktionsberechtigung betrifft dagegen eine ganze Aktion. Wenn ein normaler Nutzer einen eigentlich administrativen Endpunkt zur Benutzerverwaltung aufrufen kann, liegt eher ein Problem auf Funktionsebene vor. Beide Fehlerarten können gemeinsam auftreten. Ein Mitarbeiter darf vielleicht grundsätzlich Tickets bearbeiten, darf aber nur Tickets seines Teams ändern. Fehlt die Teamprüfung, ist es wieder BOLA.

Auch Authentifizierung und Autorisierung werden oft verwechselt. Ein gültiges Access Token beantwortet nur die Frage: „Wer stellt die Anfrage?“ Autorisierung muss zusätzlich beantworten: „Darf diese Identität diese konkrete Aktion auf diesem konkreten Objekt ausführen?“

Die OWASP Top 10 verständlich erklärt hilft dabei, solche Fehler in den größeren Kontext von Zugriffskontrolle und sicherer Anwendungsentwicklung einzuordnen.

Wo Objektberechtigungen in REST-APIs geprüft werden müssen

Prüfe nicht nur offensichtliche Abruf-Endpunkte. BOLA tritt an allen Stellen auf, an denen eine Anfrage ein bestehendes Objekt referenziert oder indirekt verändert.

Typische Beispiele sind:

• GET /customers/{id}
• GET /projects/{id}/documents
• PATCH /orders/{id}
• DELETE /files/{id}
• POST /invoices/{id}/approve
• POST /exports mit einer Kunden-ID im Request-Body
• GET /messages?conversationId=...
• POST /agent/tasks mit einer Referenz auf eine Datenquelle
• Download-Links mit Datei- oder Blob-Kennung
• Webhooks, Importjobs und asynchrone Hintergrundaufträge

Ein häufiger Fehler entsteht bei verschachtelten Ressourcen. Der Endpunkt GET /tenants/{tenantId}/projects/{projectId} darf nicht nur prüfen, ob der Nutzer Zugriff auf den Mandanten hat. Er muss zusätzlich sicherstellen, dass das Projekt tatsächlich diesem Mandanten zugeordnet ist und der Nutzer im angefragten Kontext Zugriff besitzt.

Ebenso problematisch sind Massenzugriffe. Bei POST /reports/export muss die Berechtigung für alle exportierten Datensätze gelten. Es reicht nicht, den Auftrag selbst anzulegen und erst später im Hintergrund Daten ohne Nutzerkontext zusammenzustellen.

So testest du BOLA systematisch

Der wichtigste Grundsatz lautet: Teste immer mit mindestens zwei Identitäten und mindestens zwei Objekten. Ein einzelner Testnutzer kann keine Mandantengrenze sichtbar machen.

Lege für realistische Tests eine kleine Berechtigungsmatrix an. Du brauchst mindestens:

• Nutzer A im Mandanten Alpha
• Nutzer B im Mandanten Beta
• Optional einen zweiten Nutzer im Mandanten Alpha mit anderer Rolle
• Ein Objekt von Nutzer A oder Mandant Alpha
• Ein Objekt von Nutzer B oder Mandant Beta
• Einen administrativen Testaccount, falls Admin-Funktionen existieren

Danach prüfst du jeden relevanten Endpunkt mit positiven und negativen Fällen. Positiv bedeutet: Der berechtigte Nutzer kann die vorgesehene Aktion ausführen. Negativ bedeutet: Ein anderer Nutzer, eine niedrigere Rolle oder ein Nutzer aus einem anderen Mandanten wird zuverlässig abgewiesen.

Eine praxistaugliche Checkliste:

• Rufe ein eigenes Objekt mit Nutzer A ab.
• Rufe dasselbe Objekt mit Nutzer B ab.
• Ersetze die Objekt-ID durch eine ID aus einem anderen Mandanten.
• Tausche IDs nicht nur im Pfad, sondern auch in Query-Parametern und Request-Bodies.
• Prüfe Lese-, Änderungs- und Löschoperationen getrennt.
• Prüfe fachliche Aktionen wie Freigeben, Archivieren, Exportieren oder Teilen.
• Teste Batch-Endpunkte mit einer Mischung aus erlaubten und nicht erlaubten Objekt-IDs.
• Teste indirekte Zugriffe über Downloads, Vorschaulinks, E-Mail-Links und Hintergrundjobs.
• Prüfe, ob Filter wie tenantId, ownerId oder accountId vom Client manipulierbar sind.
• Prüfe, ob Antwortdaten fremde Objekt-IDs, Mandantenkennungen oder sensible Referenzen offenlegen.

Bei einer korrekten Prüfung darf Nutzer B keine Informationen über das Objekt von Nutzer A erhalten. Ob deine API dafür mit „403 Forbidden“ oder „404 Not Found“ antwortet, hängt vom Schutzbedarf und eurem API-Design ab. Ein 404 kann die Existenz eines Objekts verschleiern. Entscheidend ist, dass weder Daten noch verändernde Nebenwirkungen entstehen.

Autorisierung im Backend richtig umsetzen

Die Berechtigungsentscheidung gehört in eine zentrale, serverseitige Kontrollschicht. Der Client darf zwar Objekt-IDs, Rolleninformationen oder einen Mandantenkontext mitsenden, diese Angaben dürfen aber nicht die alleinige Grundlage der Entscheidung sein.

Robuster ist ein Muster wie dieses: Das Backend liest die Identität und Claims aus dem verifizierten Token. Anschließend lädt oder filtert es das angefragte Objekt unter Berücksichtigung des Nutzer- und Mandantenkontexts. Erst wenn das Objekt innerhalb dieses autorisierten Bereichs gefunden wird, darf die Operation ausgeführt werden.

Problematisch sind Abfragen nach dem Muster: „Lade Objekt anhand der ID, prüfe später irgendeine Rolle.“ Besser ist: „Lade genau dieses Objekt nur dann, wenn es zur berechtigten Organisation, Rolle und Beziehung des anfragenden Nutzers passt.“

Für mandantenfähige Anwendungen sollte der Tenant-Kontext möglichst aus einer vertrauenswürdigen Quelle stammen, etwa aus dem Token, einer serverseitig verwalteten Sitzung oder einer geprüften Zuordnung. Ein frei übergebener Header wie X-Tenant-ID ist kein ausreichender Sicherheitsanker. Wenn du ihn aus technischen Gründen benötigst, muss das Backend ihn gegen die Identität des Nutzers validieren.

Auch Datenbankabfragen verdienen Aufmerksamkeit. Ein fehlender Filter auf tenant_id oder owner_id ist ein klassischer Auslöser. Bei komplexeren Systemen helfen zentrale Repository-Funktionen, Datenzugriffsrichtlinien und gegebenenfalls Row-Level Security. Diese Maßnahmen ergänzen jedoch die Anwendungslogik, sie ersetzen keine durchdachte Berechtigungsprüfung.

Grundprinzipien für sichere Webentwicklung unterstützen dabei, Sicherheitsprüfungen nicht erst nachträglich an einzelne Endpunkte anzubauen.

Automatisierte Tests gegen Berechtigungsfehler

Manuelle Tests sind unverzichtbar, aber nicht ausreichend. APIs wachsen, Endpunkte ändern sich und neue Entwickler können eine zentrale Prüfroutine umgehen. Deshalb sollten negative Autorisierungstests Teil eurer automatisierten Integrations- oder End-to-End-Tests sein.

Ein guter Testfall beschreibt nicht nur den erwarteten Erfolg, sondern ausdrücklich den unzulässigen Zugriff. Beispiel: „Nutzer aus Mandant Beta kann Rechnung aus Mandant Alpha weder lesen noch ändern noch löschen.“ Dieser Test sollte gegen eine realitätsnahe Testumgebung laufen und nicht nur gemockte Berechtigungsfunktionen prüfen.

Beziehe insbesondere diese Fälle in eure Pipeline ein:

• Besitzerzugriff und Fremdzugriff für jedes Objekt
• Zugriff über verschiedene Rollen im selben Mandanten
• Zugriff über Mandantengrenzen hinweg
• Manipulierte IDs in Pfad, Query und Body
• Batch-Anfragen mit unberechtigten Objekten
• Asynchrone Jobs und Exportfunktionen
• API-Versionen, insbesondere ältere weiterhin erreichbare Versionen
• Servicekonten und technische Tokens mit weitreichenden Rechten

Verhindere außerdem, dass Entwickler Berechtigungslogik nur in der Benutzeroberfläche umsetzen. Ein ausgeblendeter Button schützt nicht, wenn die API weiterhin erreichbar ist. Teste daher die API direkt mit Testtokens und nachvollziehbaren Requests.

Ein externer oder interner Penetrationstest ergänzt diese Tests, weil er Annahmen des Entwicklungsteams gezielt hinterfragt. Wie Befunde aus solchen Prüfungen sauber priorisiert und nachverfolgt werden, zeigen wir in Einen Pentest-Bericht lesen und umsetzen.

KI-Agenten und mobile Apps besonders absichern

Mobile Apps sind keine vertrauenswürdige Sicherheitsgrenze. Endpunkte, IDs und Requests lassen sich analysieren und verändern. Jede Berechtigungsentscheidung muss deshalb unabhängig von der App im Backend erfolgen.

Bei KI-Agenten kommt hinzu, dass ein Agent mehrere Systeme ansprechen kann. Stelle sicher, dass jeder Tool-Aufruf an die Identität, Rolle und Tenant-Zugehörigkeit des auslösenden Nutzers gebunden ist. Ein Agent darf nicht mit einem breit berechtigten Servicekonto Daten anderer Nutzer abrufen, nur weil die ursprüngliche Anfrage harmlos formuliert war.

Prüfe außerdem, ob der Agent Objekt-IDs aus Dokumenten, Chatnachrichten oder externen Quellen übernimmt. Solche Daten sind Eingaben, keine vertrauenswürdigen Berechtigungsnachweise. Für den sicheren Betrieb agentischer Schnittstellen sind die Hinweise zu MCP-Servern im Unternehmen eine sinnvolle Ergänzung.

BOLA dauerhaft vermeiden

BOLA verschwindet nicht durch schwer erratbare IDs oder einen einmaligen Pentest. Entscheidend sind klare Berechtigungsmodelle, zentrale Prüfungen, realistische negative Tests und eine konsequente Mandantentrennung in jeder Datenabfrage.

Dokumentiere für jede Ressource, wer sie lesen, ändern, löschen, teilen und exportieren darf. Mache diese Regeln für Entwicklung, Qualitätssicherung und Security sichtbar. Neue Endpunkte sollten erst freigegeben werden, wenn die Berechtigungsmatrix und die zugehörigen Negativtests vorhanden sind.

Teste ausschließlich Systeme, für die du einen klaren Auftrag und eine definierte Freigabe hast. Die rechtlichen Grenzen beim Testen gelten auch dann, wenn eine API öffentlich erreichbar ist. Passende Seminare und Termine findest du bei uns auf cmt.de.