Broken Object Level Authorization (BOLA/IDOR) in APIs verhindern

1. Was ist Broken Object Level Authorization?

Broken Object Level Authorization, kurz BOLA, beschreibt eine Schwachstelle, bei der ein Server zwar prüft, ob ein Nutzer eingeloggt ist, aber nicht, ob dieser Nutzer auch berechtigt ist, genau auf das angefragte Objekt zuzugreifen. Der eng verwandte Begriff Insecure Direct Object Reference (IDOR) beschreibt denselben Effekt aus Sicht des Angreifers: Eine direkte Objektreferenz, meist eine ID in der URL oder im Request-Body, wird einfach durchgereicht, ohne dass geprüft wird, wem das referenzierte Objekt tatsächlich gehört.

In der OWASP API Security Top 10 belegt BOLA seit Jahren konstant den ersten Platz, weil APIs die interne Struktur von Ressourcen oft direkt über Endpunkte wie /api/orders/{id} oder /api/invoices/{id} offenlegen. Jede fortlaufende oder vorhersehbare ID wird damit zu einem potenziellen Angriffsvektor, sobald die Autorisierungsprüfung pro Objekt fehlt.

2. Warum Authentifizierung allein nicht ausreicht

Authentifizierung beantwortet die Frage, wer jemand ist. Autorisierung beantwortet die Frage, was diese Person tun darf, und zwar bezogen auf eine konkrete Ressource. Viele Entwickler verwechseln beides oder verlassen sich darauf, dass ein gültiges Token automatisch auch objektbezogene Rechte mitbringt. Genau das ist der Kern von BOLA: Ein Angreifer besitzt ein eigenes, gültiges Konto und damit ein gültiges Token, nutzt dieses aber, um auf fremde Objekte zuzugreifen, indem er einfach die ID in der Anfrage verändert.

Das folgende Beispiel zeigt einen Symfony-Controller, der Bestellungen ausliefert. Die verwundbare Variante prüft nur, ob überhaupt ein Nutzer eingeloggt ist. Die abgesicherte Variante prüft zusätzlich, ob die Bestellung tatsächlich dem angemeldeten Nutzer gehört, bevor die Daten zurückgegeben werden.

<?php

declare(strict_types=1);

namespace App\Controller\Api;

use App\Entity\Order;
use App\Repository\OrderRepository;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\Routing\Annotation\Route;

final class OrderApiController extends AbstractController
{
    public function __construct(
        private readonly OrderRepository $orderRepository,
    ) {
    }

    // Verwundbar: Jeder eingeloggte Nutzer kann jede Bestellung abrufen
    #[Route('/api/orders/{id}', methods: ['GET'])]
    public function showVulnerable(int $id): JsonResponse
    {
        $order = $this->orderRepository->find($id);

        if (!$order instanceof Order) {
            throw $this->createNotFoundException();
        }

        return $this->json($order, 200, [], ['groups' => 'order:read']);
    }

    // Abgesichert: Objektbezogene Autorisierungsprüfung vor der Auslieferung
    #[Route('/api/orders/{id}', methods: ['GET'])]
    public function showSecured(int $id): JsonResponse
    {
        $order = $this->orderRepository->find($id);

        if (!$order instanceof Order) {
            throw $this->createNotFoundException();
        }

        $this->denyAccessUnlessGranted('VIEW', $order);

        return $this->json($order, 200, [], ['groups' => 'order:read']);
    }
}

3. Typische Fundstellen in bestehenden APIs

BOLA versteckt sich selten dort, wo man zuerst hinschaut. Klassische Fundstellen sind Detail-Endpunkte für einzelne Ressourcen wie Rechnungen, Bestellungen, Nachrichten oder Profile, Datei-Downloads über eine numerische oder UUID-basierte ID, sowie PATCH- und DELETE-Endpunkte, bei denen die Schreibrichtung noch seltener geprüft wird als die Leserichtung. Auch verschachtelte Ressourcen sind gefährdet, etwa /api/projects/{projectId}/tasks/{taskId}, wenn nur die Existenz der Task, aber nicht deren Zugehörigkeit zum Projekt und zum Nutzer geprüft wird.

Besonders tückisch sind interne Admin- oder Support-APIs, die ursprünglich nur für wenige Mitarbeiter gedacht waren und deshalb nachlässiger abgesichert wurden, später aber über ein Frontend oder eine mobile App für eine größere Nutzergruppe erreichbar gemacht werden, ohne dass die Autorisierungslogik nachgezogen wird.

4. Risiken und Folgen eines BOLA-Vorfalls

Ein erfolgreicher BOLA-Angriff erlaubt in der Regel den systematischen Abruf fremder Datensätze, einfach durch Hochzählen der ID. Bei personenbezogenen Daten bedeutet das einen meldepflichtigen Datenschutzvorfall nach DSGVO, bei Zahlungs- oder Vertragsdaten zusätzlich erhebliche wirtschaftliche und rechtliche Risiken. Da BOLA-Lücken oft über automatisierte Skripte ausgenutzt werden können, ist der potenzielle Schaden nicht auf einzelne Datensätze begrenzt, sondern kann den kompletten Datenbestand einer Ressource umfassen.

Neben dem direkten Datenabfluss entsteht häufig ein Vertrauensschaden, weil betroffene Kunden benachrichtigt werden müssen und der Vorfall öffentlich wird. Aufsichtsbehörden bewerten fehlende objektbezogene Zugriffskontrollen zunehmend als grobe Fahrlässigkeit, was das Bussgeldrisiko zusätzlich erhöht.

5. Systematische Prüfstrategie für bestehende APIs

Um eine bestehende API systematisch zu prüfen, hilft eine Inventarisierung aller Endpunkte, die eine ID im Pfad, in Query-Parametern oder im Body entgegennehmen. Für jeden dieser Endpunkte wird dann mit zwei Testnutzern gearbeitet: Nutzer A legt eine Ressource an, Nutzer B versucht, mit seinem eigenen gültigen Token auf die ID von Nutzer A zuzugreifen, sie zu ändern oder zu löschen.

Diese Prüfung sollte für jede HTTP-Methode getrennt erfolgen, da GET-Endpunkte oft besser geschützt sind als PATCH-, PUT- oder DELETE-Endpunkte. Ergänzend lohnt sich eine Prüfung mit manipulierten IDs außerhalb des erwarteten Bereichs sowie mit IDs, die zu gelöschten oder archivierten Objekten gehören, da Soft-Delete-Mechanismen die Autorisierungsprüfung gerne umgehen.

6. Automatisierte Tests und Tooling

Manuelle Stichproben reichen bei wachsenden APIs schnell nicht mehr aus. Sinnvoll ist ein automatisierter Testsuite-Baustein, der für jeden neuen Endpunkt mit ID-Parameter automatisch einen Negativtest generiert: Objekt mit Nutzer A anlegen, mit Nutzer B abrufen, HTTP 403 oder 404 erwarten. Wird dieser Test in die CI-Pipeline integriert, fällt ein Build zuverlässig durch, sobald ein neuer Endpunkt ohne Objektprüfung hinzukommt.

Ergänzend gibt es spezialisierte API-Security-Scanner, die eine OpenAPI-Spezifikation einlesen und automatisiert BOLA-Testfälle generieren. Diese Tools ersetzen keine manuelle Prüfung komplexer Berechtigungslogik, sind aber ein guter erster Filter, um offensichtliche Lücken früh im Entwicklungsprozess zu finden.

7. Objektbasierte Berechtigungsprüfung implementieren

In Symfony bietet sich das Voter-System an, um Autorisierungslogik zentral und testbar zu halten, statt sie in jedem Controller neu zu schreiben. Ein Voter erhält das konkrete Objekt und den aktuellen Nutzer und entscheidet anhand klarer Regeln, ob der Zugriff erlaubt ist, zum Beispiel weil der Nutzer Eigentümer der Ressource ist oder einer berechtigten Gruppe angehört.

Wichtig ist, dass diese Prüfung nicht optional in der Business-Logik verstreut wird, sondern an einer einzigen, verpflichtenden Stelle direkt nach dem Laden des Objekts stattfindet, idealerweise durchgesetzt durch einen Test, der bei fehlendem denyAccessUnlessGranted-Aufruf fehlschlägt.

8. Häufige Fehler bei der Umsetzung

Ein verbreiteter Fehler ist, die Autorisierungsprüfung nur im Frontend vorzunehmen und darauf zu vertrauen, dass die UI keine fremden IDs anzeigt. Da die API direkt ansprechbar bleibt, umgeht ein Angreifer diese Prüfung trivial. Ein weiterer Fehler ist, die Prüfung nur für den Haupt-Ressourcentyp umzusetzen, verschachtelte oder verknüpfte Objekte wie Kommentare, Anhänge oder Historieneinträge aber zu vergessen.

Auch UUIDs werden fälschlicherweise oft als ausreichender Schutz missverstanden. Eine UUID ist zwar schwer zu erraten, verhindert aber keinen BOLA-Angriff, wenn die ID durch einen anderen Kanal bekannt wird, etwa durch geteilte Links, Server-Logs oder eine vorherige, legitime Interaktion mit demselben Objekt.

9. Best Practices und Checkliste

Jede API-Route mit ID-Parameter braucht eine explizite, objektbezogene Autorisierungsprüfung nach dem Laden der Ressource und vor jeder Rückgabe oder Aenderung von Daten. Diese Prüfung gehört in eine zentrale, wiederverwendbare Komponente wie einen Voter oder eine Policy-Klasse, nicht in verstreute if-Abfragen.

Ergänzend empfiehlt sich ein Logging fehlgeschlagener Autorisierungsprüfungen, um Angriffsmuster wie systematisches ID-Hochzählen früh zu erkennen, sowie eine regelmäßige Wiederholung der in diesem Artikel beschriebenen Prüfstrategie bei jedem neuen Release mit neuen oder geänderten Endpunkten.

10. Zusammenfassung

11. FAQ: BOLA/IDOR