BOLA: Die API-Schwachstelle, die sich direkt vor aller Augen verbirgt

Stellen Sie sich vor, Sie melden sich bei Ihrer Online-Banking-Anwendung an und sehen Ihren Kontostand, Ihren Transaktionsverlauf und Ihre persönlichen Daten. Alles funktioniert genau wie erwartet. Stellen Sie sich nun vor, Sie ändern eine einzige Zahl in der URL (die Konto-ID) und sehen plötzlich die Finanzdaten einer anderen Person. Keine Hacking-Tools erforderlich. Keine ausgefeilte Exploit-Kette. Nur eine Ziffer.

Das ist kein hypothetisches Szenario. Genau diese Art von Schwachstelle führte dazu, dass T-Mobile die Daten von 37 Millionen Kunden offenlegte – bei einem 2023 bekannt gegebenen Sicherheitsvorfall. In der Folge kam es zu einem Vergleich in einer Sammelklage über 350 Millionen US-Dollar.

Dieselbe Art von Schwachstelle ermöglichte es Angreifern, auf die persönlichen Daten und Trainingsstatistiken aller Peloton-Nutzer zuzugreifen, indem sie einfach die Benutzer-IDs in API-Anfragen austauschten. Und dasselbe Schwachstellenmuster ermöglichte es bei Harbor, einer weit verbreiteten Container-Registry, einem Nutzer mit einer einfachen Wartungsrolle, ein ganzes privates Projekt auf öffentlich umzustellen und nicht verifizierte Images bereitzustellen – indem er Projektmetadaten über einen nicht autorisierten API-Aufruf manipulierte.

Die Schwachstelle, die all diesen Vorfällen zugrunde liegt, hat einen Namen: Broken Object Level Authorization (BOLA). Sie steht auf Platz 1 der OWASP API Security Top 10 und ist wohl die weitverbreitetste, gefährlichste und am meisten unterschätzte Schwachstelle in der modernen API-Sicherheit.

Was ist BOLA?

Broken Object Level Authorization ist eine Autorisierungsschwachstelle, bei der eine API oder Webanwendung nicht überprüft, ob die anfragende Person tatsächlich berechtigt ist, auf das konkrete Datenobjekt zuzugreifen, das sie ansteuern oder ändern möchte. Wenn ein Nutzer eine Ressource anfordert, etwa einen Datenbankeintrag, eine Datei oder eine Transaktion, sollte die Anwendung nicht nur prüfen, ob der Nutzer authentifiziert ist (also tatsächlich die Person ist, für die er sich ausgibt), sondern auch, ob er für die Interaktion mit genau diesem Objekt autorisiert ist (also es sehen oder ändern darf).

Fehlt diese Autorisierungsprüfung, ist sie unzureichend oder wird sie nicht konsequent durchgeführt, kann ein Angreifer auf die Daten anderer Nutzer zugreifen, indem er einfach die Objektkennung in der Anfrage manipuliert. Ändern Sie eine Kontonummer in einem URL-Parameter. Tauschen Sie eine Benutzer-ID in einem API-Header aus. Ändern Sie eine Ressourcen-ID in einer JSON-Nutzlast. Wenn der Server bei jeder Anfrage nicht überprüft, wem das Objekt gehört, gibt er Daten preis, die er schützen sollte.

Es lohnt sich, dies von der Authentifizierung abzugrenzen. Die Authentifizierung beantwortet die Frage „Wer sind Sie?“ und prüft die Identität anhand von Anmeldedaten, Tokens oder Mehr-Faktor-Verfahren. Die Autorisierung beantwortet die Frage „Was dürfen Sie tun?“ und legt fest, welche konkreten Ressourcen und Aktionen für diese Identität zulässig sind. BOLA nutzt eine Schwachstelle in der zweiten Prüfung aus. Der Nutzer ist authentifiziert, angemeldet und verifiziert. Er greift lediglich auf Objekte zu, die ihm nicht gehören – und die Anwendung unternimmt nichts, um das zu verhindern.

BOLA und IDOR: dieselbe Schwachstelle aus unterschiedlichen Blickwinkeln

Wenn Sie schon länger im Bereich Anwendungssicherheit tätig sind, wird Ihnen auffallen, dass das, was OWASP als BOLA bezeichnet, einem anderen etablierten Schwachstellentyp erstaunlich ähnlich klingt: Insecure Direct Object References (IDOR). Darüber wird in der Cybersicherheits-Community tatsächlich gestritten. Die Überschneidung der Begriffe sorgt für Verwirrung, die es sich lohnt, direkt anzusprechen.

IDOR hat seinen Ursprung in den OWASP Web Application Security Top 10, wo die Schwachstelle bereits 2007 aufgeführt wurde. Der Begriff beschreibt ein bestimmtes Angriffsmuster: Eine Anwendung gibt eine direkte Referenz auf ein internes Objekt preis, etwa einen Datenbankschlüssel, einen Dateinamen oder eine fortlaufende ID. Ein Angreifer manipuliert diese Referenz, um auf etwas zuzugreifen, das ihm nicht zusteht. IDOR konzentrierte sich vor allem auf den Mechanismus des Exploits: die vorhersagbare, erratbare oder systematisch ermittelbare Kennung, die der Angreifer manipuliert.

BOLA wurde 2019 mit den OWASP API Security Top 10 eingeführt und beschreibt dieselbe grundlegende Schwachstelle, jedoch aus einer umfassenderen Perspektive. Während IDOR auf die manipulierbare Referenz fokussiert, beschreibt BOLA das Problem treffender: eine fehlerhafte Autorisierungsprüfung auf Objektebene.

Der Schwerpunkt verlagert sich vom Angriffsvektor („Die Referenz ist unsicher“) auf die eigentliche Ursache („Die Autorisierung ist fehlerhaft“). BOLA berücksichtigt zudem ausdrücklich, dass diese Schwachstellen über einfache Manipulationen von URLs hinausgehen: Sie können in API-Anfrageinhalten, Headern, verschachtelten Objektstrukturen und über Microservice-Grenzen hinweg auftreten, wo die Autorisierungslogik möglicherweise uneinheitlich umgesetzt ist.

In der Praxis bezeichnen beide Begriffe dieselbe Schwachstellenfamilie. Ob Sie sie IDOR oder BOLA nennen: Das Kernproblem ist dasselbe. Eine Anwendung vertraut vom Nutzer bereitgestellten Kennungen, ohne serverseitig die Autorisierung für das konkret angeforderte Objekt ordnungsgemäß zu prüfen. Die Schutzmaßnahmen sind dieselben. Auch die geschäftlichen Auswirkungen sind dieselben.

Die Unterscheidung der Begriffe ist dennoch aus zwei Gründen wichtig:

• Erstens eignet sich BOLA als Begriff für moderne, API-gesteuerte Architekturen besser, weil er die Diskussion auf die Autorisierungslogik statt auf ein bestimmtes technisches Muster lenkt. In einer Welt aus Microservices, zusammensetzbaren Architekturen und zunehmend komplexen API-Ökosystemen ist es zielführender, Autorisierung ganzheitlich zu betrachten – für jeden Endpunkt und jedes Objekt –, als sich darauf zu konzentrieren, ob ein URL-Parameter erraten werden kann.

• Zweitens signalisiert die korrekte Verwendung beider Begriffe, dass Sie das gesamte Ausmaß des Problems im Web- und API-Kontext verstehen: BOLA steht auf Platz 1 der OWASP API Security Top 10, während IDOR in den OWASP Web Application Top 10 unter die allgemeinere Kategorie „Broken Access Control“ fällt.

Im weiteren Verlauf dieses Artikels verwenden wir hauptsächlich den Begriff BOLA. Denken Sie jedoch daran: Wenn Sie BOLA lesen, gehört IDOR zur selben Geschichte.

Warum BOLA besonders gefährlich ist

BOLA nimmt in der Schwachstellenlandschaft eine besonders tückische Stellung ein, denn hier treffen drei Eigenschaften zusammen, die selten gemeinsam auftreten: Die Schwachstelle lässt sich leicht ausnutzen, ist schwer zu erkennen und kann verheerende Folgen haben.

Leicht auszunutzen.

BOLA-Angriffe erfordern weder ausgefeilte Tools noch fortgeschrittene technische Kenntnisse oder komplexe Exploit-Ketten. Angreifer können mit nichts weiter als einem Browser, einem Proxy-Tool oder einem einfachen Skript nach diesen Schwachstellen suchen. Sie ändern einen Parameter und beobachten die Antwort. Werden Daten zurückgegeben, die nicht hätten zurückgegeben werden dürfen, ist die Anwendung verwundbar. Die Einstiegshürde ist praktisch null. Dadurch können weit mehr verschiedene Bedrohungsakteure diese Schwachstellen ausnutzen als die meisten anderen Schwachstellenarten.

Schwer zu testen. 

Herkömmliche Sicherheitstests haben mit BOLA zu kämpfen, denn hierbei handelt es sich nicht um technische Fehler im klassischen Sinn, sondern um Logikfehler. Eine SQL-Injection hinterlässt ein erkennbares Muster in einer Abfrage. Eine Cross-Site-Scripting-Schwachstelle (XSS) erzeugt charakteristische Nutzdaten. Bei BOLA hingegen ist die API-Anfrage vollkommen korrekt aufgebaut und syntaktisch fehlerfrei – sie gibt lediglich Daten zurück, die einem anderen Nutzer gehören. Es gibt keine fehlerhafte Eingabe, keine verdächtigen Nutzdaten und kein anomales Muster. Die Anfrage wirkt legitim. Die Antwort wirkt legitim. Falsch ist nur, dass die anfragende Person genau diese Antwort nicht hätte erhalten dürfen.

Kann moderne Schutzmaßnahmen umgehen. 

Auch Unternehmen mit einer ausgereiften Sicherheitsstrategie – einschließlich Web Application Firewalls, API-Gateways, Ratenbegrenzung und Authentifizierungskontrollen – können für BOLA anfällig sein. Diese Schutzmaßnahmen sollen unbefugte Zugriffe, fehlerhafte Anfragen und bekannte Angriffsmuster erkennen. BOLA bewegt sich jedoch vollständig innerhalb des normalen, authentifizierten Datenverkehrs. Der Nutzer verfügt über gültige Anmeldedaten. Das Anfrageformat ist korrekt. Das API-Gateway sieht einen authentifizierten Nutzer, der eine legitim wirkende Anfrage stellt. Nichts löst einen Alarm aus.

Die geschäftlichen Folgen entsprechen dem Schweregrad: Datenlecks, bei denen Millionen Datensätze offengelegt werden. Strafen durch Aufsichtsbehörden. Sammelklagen. Reputationsschäden, deren Behebung Jahre dauert. Wenn ein Angriff so einfach ist wie das Ändern einer Zahl in einer URL, stellt sich nicht die Frage, ob Angreifer es versuchen werden, sondern ob Ihre Anwendungen sie daran hindern.

Wie entsteht BOLA überhaupt?

BOLA-Schwachstellen sind selten das Ergebnis eines einzelnen Fehlers in der Entwicklung. Meist entstehen sie durch eine Reihe grundlegend falscher Annahmen darüber, wie APIs entworfen, entwickelt und gewartet werden.

Entwickler verlassen sich häufig zu sehr auf clientseitige Prüfungen und nehmen an, Nutzer würden Objekt-IDs oder Tokens nicht manipulieren. Diese Annahme ist grundlegend falsch, wie die oben genannten Sicherheitsvorfälle wiederholt belegen. Hinzu kommt, dass Autorisierungslogik an verschiedenen Endpunkten oft uneinheitlich umgesetzt wird. Ohne ein zentrales Autorisierungs-Framework – wenn jeder Endpunkt eigene Zugriffskontrollen implementiert oder diese ganz vergisst – sind Lücken unvermeidlich. Eine Anwendung kann die Autorisierung bei 99 von 100 Endpunkten korrekt durchsetzen. Der eine übersehene Endpunkt wird zum Einfallstor.

Auch die Testverfahren verschärfen das Problem. Manuelle Sicherheitstests und Automatisierung mit geringer Abdeckung erkennen BOLA nur selten, denn diese Schwachstellen folgen keinem Muster. Sie lassen sich nicht durch die Suche nach bekannten Signaturen finden. Eine wirksame BOLA-Erkennung setzt ein Verständnis der Geschäftslogik, der Dateneigentümerschaft und des Kontexts jeder Anfrage voraus – Fähigkeiten, die automatisierte Tools lange Zeit nicht boten.

Und dann ist da noch die Realität moderner Softwareentwicklung: Geschwindigkeit zählt. Entwicklungsteams stehen ständig unter Druck, APIs schnell bereitzustellen und Geschäftsanforderungen zu erfüllen. Dabei wird die Überprüfung der Autorisierung häufig zugunsten der Feature-Entwicklung zurückgestellt. Die daraus entstehende BOLA-Schwachstelle bleibt womöglich monatelang oder jahrelang unentdeckt – bis ein Angreifer sie findet.

Die Herausforderung bei der Erkennung

BOLA in großem Umfang zu erkennen, zählt zu den schwierigsten Aufgaben der Anwendungssicherheit. Es lohnt sich, die Gründe dafür zu verstehen.

Die zentrale Herausforderung besteht darin, dass eine wirksame BOLA-Erkennung Kontextverständnis erfordert. Der Scanner muss nicht nur erkennen, dass eine API Daten zurückgibt, sondern auch, ob genau dieser Nutzer auf diese Daten zugreifen darf. Ist diese Ressource öffentlich oder privat? Ist der anfragende Nutzer Eigentümer dieses Objekts? Darf ein Nutzer mit dieser Rolle dieses Feld sehen? Die Antworten hängen vollständig von der Geschäftslogik und den Autorisierungsregeln der Anwendung ab. Sie lassen sich weder durch Musterabgleich noch durch signaturbasierte Erkennung ermitteln.

Einfache Ansätze zur BOLA-Erkennung, etwa die Prüfung, ob eine Änderung der ID andere Daten zurückgibt, führen zu inakzeptabel vielen Fehlalarmen. Viele APIs stellen absichtlich öffentliche Ressourcen bereit, auf die jeder authentifizierte Nutzer zugreifen kann. Produktkataloge, öffentliche Profile und freigegebene Dokumente sollen für verschiedene Nutzer zugänglich sein. Wird jeder Fall, in dem zwei Nutzer auf dieselbe Ressource zugreifen können, als potenzielle BOLA-Schwachstelle eingestuft, entsteht so viel Rauschen, dass echte Befunde untergehen. AppSec-Teams, die ohnehin schon stark ausgelastet sind, können es sich nicht leisten, Hunderte Fehlalarme zu untersuchen, um die wenigen tatsächlichen Autorisierungsfehler zu finden.

Deshalb liefern manche Wettbewerber, die BOLA-Erkennung anbieten, nur oberflächliche Ergebnisse. Ohne die Fähigkeit, den Kontext des Zugriffs und mögliche Zugriffsbeschränkungen zu verstehen, bleiben Erkennungsmechanismen naiv und das Verhältnis von Signal zu Rauschen schlecht.

Warum das heute wichtiger ist denn je

Die Dringlichkeit der BOLA-Erkennung ist nicht nur theoretischer Natur. Mehrere zusammenlaufende Entwicklungen sorgen dafür, dass diese Schwachstellenart heute häufiger auftritt und gefährlicher ist als je zuvor.

1. Die Angriffsfläche von APIs wächst. 

Moderne Anwendungen bestehen nicht mehr aus monolithischen Codebasen. Sie setzen sich aus Microservices zusammen, die über APIs miteinander kommunizieren. Zusammensetzbare Architekturen lösen die alten Code-Monolithen ab. Jeder neue Microservice, jeder neue API-Endpunkt und jede neue Integration kann eine Angriffsfläche für BOLA schaffen. Die schiere Zahl der API-Endpunkte in typischen Unternehmensumgebungen ist um Größenordnungen gestiegen. Gleichzeitig muss die Autorisierungslogik an jedem einzelnen davon korrekt implementiert sein.

2. KI-generierter Code verschärft das Problem. 

76 % der Entwickler nutzen inzwischen KI-Coding-Tools oder planen deren Einsatz (Stack Overflow, 2024). Eine Studie mit fünf großen KI-Modellen ergab, dass mindestens 48 % der von ihnen generierten Code-Snippets Schwachstellen enthielten. Wenn Code mit Maschinengeschwindigkeit entsteht, wächst auch die Angriffsfläche für Autorisierungsfehler entsprechend. Entwickler, die mit KI-Coding-Assistenten arbeiten, bringen mehr Code schneller in den Einsatz. Die darin enthaltene Autorisierungslogik ist jedoch nur so gut wie die Prompts und Prüfprozesse, die sie begleiten. In vielen Fällen funktioniert der generierte Code, lässt aber die Autorisierungsprüfungen aus, die ein sicherheitsbewusster Entwickler eingebaut hätte.

3. KI-Agenten schaffen neue Angriffsvektoren. 

Der Aufstieg autonomer KI-Agenten, die über APIs mit internen Daten und Diensten interagieren, verschärft das Problem zusätzlich. Diese Agenten kommunizieren über dieselben API-Endpunkte wie menschliche Nutzer, arbeiten aber mit Maschinengeschwindigkeit und können mehrere API-Aufrufe auf eine Weise verketten, die bei menschlichen Nutzern nicht üblich ist. Sind diese API-Endpunkte durch BOLA-Schwachstellen gefährdet, lässt sich ein Agent als Waffe einsetzen – oder ein Angreifer kann dieselben Endpunkte ausnutzen, die der Agent verwendet –, um Daten in großem Umfang abzugreifen oder Ressourcen zu verändern.

Ein Agent, der eine durch BOLA kompromittierte API nutzt, ist nicht einfach nur eine Schwachstelle: Er wird zur automatischen Maschine für Datenabfluss.

Vier der fünf wichtigsten Einträge in den OWASP API Security Top 10 betreffen Autorisierungs- und Authentifizierungsprobleme. BOLA ist kein Einzelfall, sondern das sichtbarste Symptom einer systemischen Herausforderung beim Umgang moderner Anwendungen mit Zugriffskontrollen. Wer BOLA erkennt, schafft die Grundlage, um auch die umfassendere Gruppe von Autorisierungsfehlern anzugehen, auf die der Großteil der kritischen API-Sicherheitsrisiken zurückgeht.

Ein neuer Ansatz: KI-gestützte BOLA-Erkennung

Die Herausforderung, die BOLA so hartnäckig macht, besteht im Wesentlichen darin, den Kontext zu verstehen. Genau hier verändern die jüngsten Fortschritte bei KI und großen Sprachmodellen (LLMs) die Lage.

Der von Snyk API & Web entwickelte Ansatz nutzt LLMs, um den Kontext von API-Anfragen und der Autorisierungslogik zu analysieren. Damit geht er über herkömmliche DAST-Techniken hinaus: Er klassifiziert, wem Inhalte gehören, und ermittelt, ob die anfragende Person auf eine Antwort zugreifen darf. Statt sich auf einfache Heuristiken zum Austausch von IDs zu verlassen, die Fehlalarme erzeugen, kann die KI-gestützte Erkennungs-Engine beurteilen, ob Daten öffentlich oder privat sind, ob die anfragende Person tatsächlich berechtigt ist und ob die Autorisierungsgrenze wirklich verletzt wurde.

Dabei geht es nicht darum, die Grundlagen dynamischer Anwendungssicherheitstests zu ersetzen. DAST bleibt unverzichtbar: Anwendungen werden von außen nach innen getestet, indem die Angriffsfläche mit Payloads in großem Umfang untersucht wird – so, wie es ein Angreifer tun würde. KI ergänzt diese Testmethode um kontextbezogene Intelligenz und ermöglicht so die Erkennung von Schwachstellen, die für Musterabgleich unsichtbar sind. Das Ergebnis: eine BOLA-Erkennung mit deutlich weniger Fehlalarmen. AppSec-Teams erhalten dadurch umsetzbare Befunde, auf die sie sofort reagieren können, statt störender Meldungen, die sie erst herausfiltern müssen.

Und BOLA ist erst der Anfang. Derselbe KI-gestützte Ansatz wird auf weitere Autorisierungs- und Authentifizierungsfehler in den OWASP API Security Top 10 ausgeweitet, denn die technische Herausforderung, den Kontext der Geschäftslogik zu verstehen, betrifft die gesamte Gruppe von Schwachstellen bei Zugriffskontrollen. Die Erkennung von BOLA schafft die Grundlage für einen grundlegend intelligenteren Ansatz beim Testen der API-Sicherheit.

Was Sicherheitsverantwortliche fragen sollten

Wenn Sie für das Anwendungssicherheitsprogramm Ihres Unternehmens verantwortlich sind, sollte BOLA ganz oben auf Ihrer Risikobewertung stehen. Stellen Sie sich folgende Fragen:

Haben Sie einen Überblick darüber, wie die Autorisierung über Ihre API-Endpunkte hinweg implementiert ist, und ist diese Implementierung einheitlich? Wo sie uneinheitlich ist, hat BOLA leichtes Spiel. Ein zentralisiertes Autorisierungs-Framework, das für alle Services gilt, ist die wirksamste architektonische Schutzmaßnahme.

Können Ihre aktuellen Test-Tools BOLA tatsächlich erkennen, oder behaupten sie das nur, liefern aber hauptsächlich Fehlalarme? BOLA-Erkennung ist nicht gleich BOLA-Erkennung. Verlangen Sie Belege für die Genauigkeit: Fehlalarmraten, Erkennungsmethode und Ergebnisse aus der Praxis.

Wie berücksichtigen Sie die Auswirkungen von KI-generiertem Code auf die Autorisierung? Wenn Ihre Entwickler KI-Coding-Assistenten nutzen, ist der ausgelieferte Code möglicherweise funktional korrekt, aber bei der Autorisierung unvollständig. Ihre Testmethode muss aufdecken, was bei einer Code-Überprüfung möglicherweise übersehen wird.

Und schließlich: Testen Sie von außen nach innen? Autorisierungsfehler wie BOLA werden erst dann vollständig sichtbar, wenn Sie die Anwendung so testen, wie es ein Angreifer tun würde: indem Sie laufende APIs und Webanwendungen mit echten Anfragen und Payloads untersuchen und dabei die Perspektive einer Person einnehmen, die auf etwas zugreifen möchte, wozu sie nicht berechtigt ist. Statische Analysen können potenzielle Probleme im Code erkennen. Dynamische Tests zeigen, ob sie tatsächlich ausnutzbar sind.

BOLA steht aus gutem Grund auf Platz 1 der OWASP API Security Top 10. Die Schwachstelle ist weit verbreitet, schwer zu finden und kann bei Ausnutzung Schäden in Millionenhöhe und Millionen kompromittierter Datensätze zur Folge haben. Die gute Nachricht: Das Erkennungsproblem ist nicht länger unlösbar. KI-gestützte Ansätze ermöglichen es, diese Schwachstellen mit einer Genauigkeit und einem Kontextverständnis zu finden, die herkömmliche Tools nie erreichen konnten. Die Frage ist, ob Ihr Unternehmen sie findet, bevor es ein Angreifer tut.