BOLA und IDOR verhindern: Wer darf auf diesen Datensatz zugreifen?

BOLA und IDOR beschreiben das fehlende Recht am Objekt

Eine Objektreferenz ist beispielsweise die ID eines Berichts im Pfad /reports/bericht-7. Sie sagt, welchen Bericht der Client meint. IDOR steht für Insecure Direct Object Reference: Der kontrollierbare Verweis führt zu einem Zugriff, für den die notwendige Berechtigung fehlt. BOLA, Broken Object Level Authorization, bezeichnet in den OWASP API Security Top 10 die fehlende oder fehlerhafte Berechtigung auf Objektebene. Die Begriffe überschneiden sich stark; für die Behebung zählt die ausgelassene Entscheidung.

Die Referenz kann auch in einem JSON-Feld, einer Suchbedingung oder einem GraphQL-Argument stehen. Eine schwer erratbare UUID erschwert blindes Raten, erteilt aber kein Zugriffsrecht. Schon ein regulärer Freigabelink kann eine ID bekannt machen. OWASP verlangt deshalb die Entscheidung über die konkrete Aktion und das konkrete Objekt, unabhängig vom Format seiner Kennung. OWASP API1:2023.

Davon zu unterscheiden sind Funktionsrechte: Darf diese Person überhaupt Berichte exportieren? Und Feldrechte: Darf sie im erlaubten Bericht auch interne Kommentare sehen? Alle drei Entscheidungen können für denselben Aufruf nötig sein.

Beschreiben Sie erlaubte Zugriffe, bevor Sie Code ändern

„Jeder sieht nur seine eigenen Daten“ passt zu einem persönlichen Notizbuch. Für ein Teamprodukt wäre diese Regel oft falsch: Eine Kollegin darf einen freigegebenen Bericht lesen, aber nicht löschen. Ein Supportkonto besitzt möglicherweise eine ausdrücklich begrenzte Sonderbefugnis. Solche Ausnahmen brauchen eine konkrete Regel statt eines pauschalen Administratorzugangs.

Für eine fiktive Berichts-API könnte die Entscheidung so aussehen:

Die Tabelle ist ein Beispiel für einen Produktvertrag, keine allgemeine Pflichtregel. Stellen Sie bei Ihrer eigenen Tabelle auch öffentliche Objekte, geteilte Ressourcen und Dienstkonten ausdrücklich dar. Ein absichtlich öffentlicher Katalog benötigt andere Regeln als eine Rechnung.

Binden Sie die Entscheidung an den tatsächlichen Datenzugriff

Der Server benötigt eine verifizierte Identität, die gewünschte Aktion und vertrauenswürdige Informationen über das Objekt. Eine vom Client gesendete user_id, owner_id oder tenant_id ist zunächst eine Behauptung beziehungsweise Auswahl. Sie darf nicht selbst die Erlaubnis liefern.

Legen Sie die Regel an eine Stelle, die alle relevanten Zugriffspfade durchlaufen. Eine Anwendung kann berechtigte Datensätze bereits in der Datenbankabfrage einschränken oder ein geladenes Objekt vor Ausgabe und Änderung durch eine zentrale Policy prüfen. Entscheidend ist, dass kein direkter, verschachtelter oder später hinzugefügter Weg die Regel auslässt. Prüfen Sie auch Listen, Suche, Exporte, Downloadlinks, Sammeloperationen und Hintergrundaufträge. OWASP IDOR Prevention.

Bei einer Änderung muss die Berechtigung noch zur ausgeführten Änderung passen. Wenn beispielsweise eine Freigabe zwischen Prüfung und Speicherung entzogen werden kann, klären Sie die zulässige Gleichzeitigkeit. Eine passende Transaktion, Sperre oder bedingte Datenbankoperation kann nötig sein; eine frühe Middlewareprüfung allein löst diesen Zustand nicht.

Kleines Beispiel: Eine Lesefreigabe ist kein Eigentumsrecht

Die folgende reine Python-Funktion illustriert ausschließlich die Leseregel der Beispielanwendung. principal enthält bereits serverseitig geprüfte, aktuelle Mitgliedsdaten; report stammt aus dem eigenen Datenbestand. Diese Voraussetzungen dürfen nicht durch ungeprüfte Requestfelder ersetzt werden.

def may_read_report(principal, report):
    if not principal["active_member"]:
        return False
    if principal["tenant_id"] != report["tenant_id"]:
        return False
    return (
        principal["id"] == report["owner_id"]
        or principal["id"] in report["reader_ids"]
    )

Die Funktion erlaubt einem benannten Leser Zugriff, ohne ihn zum Eigentümer zu machen. Für Änderungen wäre eine andere Regel nötig. Auf sie folgt außerdem eine eigene Auswahl der zurückgegebenen Felder. Das Beispiel enthält weder Anmeldung noch Datenbank, Fehlerantwort, Widerrufscache oder Transaktionsschutz. Es ist lokal mit synthetischen erlaubten und verbotenen Fällen geprüft; es ist kein fertiges Berechtigungsmodul.

Fehlende oder ungültige Policy-Daten dürfen nicht zu einer Freigabe führen. Legen Sie fest, wie die Anwendung diese Fehler geschlossen behandelt und intern unterscheidbar protokolliert. Geben Sie dabei keine fremden Objektdetails in der Fehlerantwort preis.

Prüfen Sie erlaubte und verbotene Fälle im selben Ablauf

Bereiten Sie in einer isolierten Entwicklungs- oder Testumgebung zwei eigene Identitäten, getrennte Testobjekte und eine absichtliche Freigabe vor. Nutzen Sie den regulären Anwendungsweg mit derselben Policy wie im späteren Betrieb. Für jede Zeile Ihrer Regel sollten Sie die fachlich erwartete Wirkung kennen.

Ein 403 oder 404 kann zum Fehlervertrag passen. Der Status allein beweist die Regel jedoch nicht: Eine Antwort könnte trotzdem Daten enthalten, und eine Änderung könnte vor der Ablehnung schon erfolgt sein. Kontrollieren Sie bei Schreibfällen deshalb auch den gespeicherten Zustand und ausgelöste Aufträge. Die Fehlerreferenz erklärt die Statuswahl.

Führen Sie engere Regeln kontrolliert ein

Vergleichen Sie die neue Regel zuerst mit den legitimen Freigaben des Produkts. Ein pauschaler Eigentümerfilter kann bestehende Teamarbeit unabsichtlich abschalten. Übernehmen Sie bekannte erlaubte Abläufe als Positivfälle und ergänzen Sie die unerlaubten Gegenfälle. Dokumentieren Sie, welche Wege und Objektarten noch fehlen.

Wenn die Einführung gültige Zugriffe blockiert, untersuchen Sie die konkrete Regel oder Mitgliedsdaten. Als sichere Rücknahme kommen eine zuvor geprüfte restriktive Policy oder das vorübergehende Abschalten der betroffenen Funktion infrage. Die Objektprüfung ganz zu entfernen wäre keine sichere Fehlerbehebung. OWASP empfiehlt, Berechtigungen standardmäßig zu verweigern und ihre Durchsetzung durch Tests zu erhalten. OWASP Authorization.

Was der öffentliche Check hier beantworten kann

Der API Security Check prüft keine angemeldeten Identitäten, Objektfreigaben oder Änderungen an Ihren Datensätzen. Ein sauberer Header oder eine gute Note liefert deshalb keinen Nachweis gegen BOLA oder IDOR. Dafür brauchen Sie die eigene Rechtebeschreibung, Code- und Datenzugriffssichtung sowie passende Verhaltensprüfungen.

Bei mehreren Organisationen führt Mandantentrennung durch Datenbank, Cache und Jobs. Der Leitfaden API-Sicherheit selbst prüfen ordnet die einzelnen Nachweise in einen begrenzten Gesamtprüfweg ein. Für einen vorhandenen öffentlichen Scannerbefund erklärt HTTP-Befunde lesen, welche Aussage tatsächlich beobachtet wurde.

Passende nächste Schritte