Broken Access Control

Broken Access Control bezeichnet eine Klasse von Sicherheitslücken, bei denen eine Anwendung zwar weiß, wer ein Nutzer ist, aber nicht konsequent prüft, was dieser Nutzer tun darf. Ein eingeloggter Kunde liest fremde Bestellungen, ein Redakteur vergibt sich selbst Admin-Rechte, ein Skript ruft eine Funktion auf, die nur im Backend sichtbar sein sollte. Die Kategorie führt die OWASP Top 10 seit 2021 an und steht auch in der Ausgabe 2025 als A01 auf Platz 1.

Der Begriff wird oft mit „schlechte Login-Sicherheit“ verwechselt. Das trifft es nicht. Authentifizierung beantwortet die Frage „Wer bist du?“, Autorisierung die Frage „Was darfst du?“. Broken Access Control ist das Versagen bei der zweiten Frage. Die Anwendung hat den Nutzer korrekt erkannt und lässt ihn trotzdem an Daten oder Funktionen, die ihm nicht zustehen.

Genau deshalb ist die Kategorie so hartnäckig: Kein Framework kann sie für dich lösen. Shopware weiß nicht, dass Kunde 4711 die Rechnung von Kunde 4712 nicht sehen darf. NestJS liefert Guards, aber ein Guard, den niemand an eine Route hängt, schützt nichts. Die Regeln, wer was darf, stammen aus deiner Fachlichkeit, und nur du kannst sie in Code gießen.

Warum Broken Access Control seit 2021 auf Platz 1 steht

OWASP ordnet der Kategorie A01:2025 insgesamt 40 CWEs zu, also 40 verschiedene Schwachstellenmuster aus dem MITRE-Katalog. In den Testdaten lag die durchschnittliche Incidence Rate bei 3,74 Prozent, in einzelnen Datensätzen bei bis zu 20,15 Prozent. Dahinter stehen 1.839.701 einzelne Fundstellen und 32.654 veröffentlichte CVEs, mehr als in jeder anderen Kategorie (Quelle: OWASP Top 10:2025, A01).

Die Incidence Rate meint bei OWASP den Anteil der getesteten Anwendungen, in denen mindestens eine Schwachstelle dieser Kategorie gefunden wurde. 3,74 Prozent klingen moderat. Die Zahl der Fundstellen zeigt das eigentliche Bild: Wo Access Control bricht, bricht es selten an einer Stelle, sondern an Dutzenden Endpunkten gleichzeitig, weil dasselbe fehlende Muster im ganzen Code kopiert wurde.

Neu in der Ausgabe 2025 ist, dass Server-Side Request Forgery nicht mehr als eigene Kategorie geführt wird, sondern als CWE-918 in A01 aufgeht. Die Logik dahinter: Ein Server, der auf Zuruf beliebige URLs abruft, überschreitet eine Zugriffsgrenze, nur eben nach innen statt nach außen. Weitere prominente CWEs der Kategorie sind CWE-200 (Offenlegung sensibler Informationen), CWE-352 (CSRF) und CWE-639 (Autorisierungs-Bypass über einen vom Nutzer kontrollierten Schlüssel).

Die wichtigsten Ausprägungen

Broken Access Control ist keine einzelne Lücke, sondern ein Sammelbegriff. Die Ausprägungen unterscheiden sich darin, welche Grenze überschritten wird: die zwischen zwei Nutzern, die zwischen Rollen, die zwischen Browser und Server oder die zwischen Anwendung und internem Netz. Die folgende Übersicht ordnet die sechs häufigsten Muster ein.

IDOR: der Klassiker der Kategorie

IDOR ist das häufigste Muster und zugleich das am leichtesten zu testende. Die Route prüft, ob ein gültiger Token vorliegt, aber nicht, ob der angefragte Datensatz dem Token-Inhaber gehört. Ein Tester zählt die ID um eins hoch und sieht, was passiert. MITRE beschreibt CWE-639 als Fall, in dem die Autorisierungsfunktion nicht verhindert, „dass ein Nutzer durch Ändern des Schlüsselwerts auf die Daten eines anderen Nutzers zugreift“ (CWE-639, MITRE).

Mass Assignment: die stille Rechteausweitung

Mass Assignment ist IDOR in die andere Richtung. Nicht der Lesezugriff ist das Problem, sondern der Schreibzugriff auf Felder, die der Nutzer gar nicht sehen sollte. Ein Update-Endpunkt nimmt ein komplettes Objekt entgegen, mappt es auf die Datenbank, und plötzlich ist das Feld role oder aclRoles beschreibbar. Das Muster ist deshalb tückisch, weil der normale Request völlig harmlos aussieht. Erst ein zusätzliches Feld im JSON macht daraus eine Rechteausweitung.

Wie Broken Access Control in Shops und APIs entsteht

In einem Onlineshop gibt es mindestens drei Zugriffsgrenzen: zwischen Kunden untereinander, zwischen Kunde und Backend und zwischen Backend-Rollen untereinander. Jede davon muss an jedem Endpunkt geprüft werden, der Daten liest oder schreibt. Die Store API von Shopware ist öffentlich erreichbar, der Sales-Channel-Key liegt in jeder Headless-Storefront im Client. Was dort ohne Kontext-Token erreichbar ist, ist für die Welt erreichbar.

Im Admin-Bereich verschiebt sich das Problem auf die Rollen. Shopware bringt ein feingranulares ACL-System mit, aber die Frage, ob ein Nutzer, der Benutzer bearbeiten darf, auch Rollen vergeben darf, die über seine eigenen hinausgehen, ist eine Fachfrage. Wird sie im Code nicht gestellt, entsteht Privilege Escalation. Ähnliches gilt für Integrationen und Apps: Wer Events abonnieren darf, bekommt nicht automatisch das Recht, die Daten dieser Events zu lesen.

In einem NestJS-Backend entsteht die Lücke meist zwischen Guard und Service. Der Guard prüft das JWT, der Controller nimmt die ID aus der URL, der Service lädt den Datensatz. Nirgends fragt jemand, ob order.customerId mit request.user.id übereinstimmt. Der Code ist sauber, die Tests sind grün, und jeder eingeloggte Nutzer sieht alle Bestellungen.

Ein zweiter typischer Entstehungsort sind Frontends, die Berechtigungen nur in der Oberfläche durchsetzen. Der Button „Löschen“ wird ausgeblendet, der DELETE-Endpunkt dahinter prüft nichts. OWASP nennt genau dieses Szenario, den Umgehungsversuch über direkte API-Aufrufe, als eines von drei Beispielangriffen für A01. Ein Angreifer braucht dafür kein Werkzeug außer den Entwicklertools seines Browsers.

Realbeispiele aus 2021 und 2026

Am 25. August 2026 schloss Shopware mit 6.7.13.1 und 6.6.10.23 eine Lücke, die als Nachfolger von CVE-2026-48010 geführt wird: Ein authentifizierter Admin-Nutzer mit dem Recht, Benutzer zu bearbeiten, konnte über das Feld aclRoles im Update-Request zusätzliche Rollen vergeben, die über seine eigenen Rechte hinausgingen. CVSS 6,5, Muster Mass Assignment plus Privilege Escalation (GHSA-4wpv-5fvv-c3xp).

Drei Wochen später, am 16. September 2026, folgte mit 6.7.14.1 und 6.6.10.25 ein schwererer Fall. Nutzer oder Integrationen mit dem Recht, Webhooks anzulegen, erhielten Event-Daten, für die sie keine Leseberechtigung hatten: Kundendaten, Bestellungen und Token zur Kontowiederherstellung. CVSS 9,6, also kritisch. Shopware empfahl als Workaround, das Webhook-Recht auf vertrauenswürdige Administratoren zu beschränken und bestehende Webhook-Registrierungen zu prüfen (GHSA-r432-q883-wgvf).

Beide Fälle haben eine Gemeinsamkeit: Die Lücke lag nicht im Login, sondern eine Ebene dahinter, in der Frage, ob ein bereits legitimierter Akteur eine bestimmte Operation ausführen darf. Das ist der Kern von Broken Access Control, und es ist der Grund, warum die Kategorie auch in reifen Produkten mit professionellem Security-Prozess immer wieder auftaucht.

Ein Beispiel außerhalb von Shopware: Im Januar 2021 meldeten die Forscher von Pen Test Partners an Peloton, dass die Endpunkte /stats/workouts/details und die GraphQL-Schnittstelle ohne Authentifizierung Nutzer-IDs, Standort, Alter, Geschlecht und Trainingsdaten herausgaben. Der erste Fix im Februar 2021 verlangte einen Login, womit die Daten für alle drei Millionen Abonnenten lesbar blieben, auch bei auf „privat“ gesetzten Profilen. Erst nach der Veröffentlichung am 5. Mai 2021 wurde die Autorisierung wirklich nachgezogen (Pen Test Partners, 2021).

Der Peloton-Fall ist lehrreich, weil er den häufigsten Irrtum zeigt: Authentifizierung nachrüsten löst kein Autorisierungsproblem. Die Frage „Darf dieser Nutzer diesen Datensatz sehen?“ war nach dem ersten Fix genauso unbeantwortet wie davor.

Gegenmaßnahmen, die wirken

Die wirksamste Einzelmaßnahme heißt Deny by Default: Jede Route ist gesperrt, bis jemand sie ausdrücklich freigibt. In NestJS bedeutet das einen global registrierten Auth-Guard, von dem öffentliche Routen per Decorator ausgenommen werden, nicht umgekehrt. Wer vergisst, eine Route zu markieren, bekommt dann einen 403 statt eines Datenlecks. Die OWASP-Dokumentation nennt das Prinzip an erster Stelle, zusammen mit der Wiederverwendung eines zentralen Mechanismus statt Einzellösungen pro Controller (OWASP Authorization Cheat Sheet).

Die zweite Maßnahme ist der serverseitige Ownership-Check. Ein Guard prüft die Rolle, aber die Frage „gehört dieser Datensatz diesem Nutzer?“ lässt sich nur mit dem geladenen Datensatz beantworten. Deshalb gehört der Check in den Service oder in die Datenbankabfrage selbst: Die Query filtert von vornherein auf customerId = :currentUser, sodass fremde Datensätze gar nicht erst geladen werden. Ein 404 für fremde IDs ist in dieser Variante kein Fehler, sondern das gewünschte Verhalten.

// NestJS: Ownership-Check im Service, nicht nur Rollen-Check im Guard
async findOrderForUser(orderId: string, userId: string) {
  const order = await this.orders.findOne({
    where: { id: orderId, customerId: userId },
  });
  if (!order) throw new NotFoundException(); // fremde IDs sehen aus wie nicht existent
  return order;
}

Dritter Baustein ist ein Rollenmodell, das dem Least-Privilege-Prinzip folgt. RBAC reicht für die meisten Mittelstandsanwendungen aus, solange die Rollen eng geschnitten sind und Rechte-Zuweisungen selbst wieder unter Rechte-Kontrolle stehen. Der Shopware-Fall vom August 2026 zeigt genau diese Lücke: Das Recht „Benutzer bearbeiten“ durfte nicht implizit das Recht „beliebige Rollen vergeben“ enthalten.

Für Mass Assignment gilt: Update-Endpunkte nehmen DTOs mit Whitelist entgegen, keine ganzen Entitäten. In NestJS leistet das die ValidationPipe mit whitelist: true und forbidNonWhitelisted: true, die unbekannte Felder nicht nur ignoriert, sondern den Request ablehnt. Felder wie role, aclRoles oder isAdmin gehören in kein Nutzer-DTO.

Vierter Baustein sind Tests, die Autorisierung explizit prüfen. Ein Integrationstest pro Ressource, der mit dem Token von Nutzer A auf den Datensatz von Nutzer B zugreift und einen 403 oder 404 erwartet, kostet wenige Minuten und fängt die Mehrheit der IDOR-Fälle. OWASP empfiehlt zudem, fehlgeschlagene Zugriffsprüfungen zu loggen und bei Häufung zu alarmieren: Wer ID-Bereiche durchprobiert, hinterlässt ein deutliches Muster.

SSRF schließlich verlangt eine eigene Behandlung, weil hier nicht der Nutzer, sondern der Server die Grenze überschreitet. Vom Client gelieferte URLs werden gegen eine Allowlist geprüft, interne Adressbereiche und die Metadaten-Adresse von Cloud-Providern werden blockiert, und DNS wird zum Zeitpunkt der Verbindung erneut aufgelöst. Details stehen im Eintrag zu Server-Side Request Forgery.

Wer ein Shopware- oder NestJS-System mit vielen Rollen und Integrationen betreibt, sollte das Rechtemodell einmal strukturiert durchgehen lassen. In der Enterprise-Software-Entwicklung gehört das zur Architekturarbeit, nicht zur Nachbesserung.

Abgrenzung zu verwandten Begriffen

Identification and Authentication Failures (A07:2025) betreffen die Frage, ob die Anwendung einen Nutzer korrekt erkennt: schwache Passwörter, fehlende Mehrfaktor-Authentifizierung, Session-Tokens in der URL, kein Schutz gegen Credential Stuffing. Broken Access Control setzt dagegen voraus, dass die Erkennung funktioniert hat, und beschreibt, was danach schiefgeht. Der Peloton-Fall macht die Grenze sichtbar: Nach dem ersten Fix war A07 gelöst, A01 nicht.

Security Misconfiguration (A02:2025) umfasst falsch gesetzte Defaults, offene Debug-Modi, Standardpasswörter und fehlende Härtung. Die Überschneidung mit A01 ist real: Ein Admin-Panel, das wegen fehlender Konfiguration öffentlich erreichbar ist, kann unter beide Kategorien fallen. Die Faustregel: Liegt die Ursache in einer Einstellung außerhalb des eigenen Codes, ist es Misconfiguration. Liegt sie in einer fehlenden Prüfung im Code oder im Rechtemodell, ist es Broken Access Control.

Injection (A05:2025) ist ein anderer Mechanismus: Hier wird eingeschleuster Code vom Interpreter ausgeführt. Injection kann allerdings als Folge dazu führen, dass Zugriffsgrenzen fallen, etwa wenn eine SQL-Injection Daten anderer Mandanten liest. OWASP ordnet nach der Ursache zu, nicht nach der Wirkung.

Häufige Fragen

Ist Broken Access Control durch einen Scanner auffindbar?

Nur teilweise. Automatische Scanner finden Force Browsing und fehlende CSRF-Token zuverlässig. IDOR und Privilege Escalation erfordern Wissen darüber, welcher Nutzer welche Daten sehen darf, und dieses Wissen hat kein Scanner. Deshalb gehören zwei Testkonten mit unterschiedlichen Rollen und ein Satz Integrationstests, die gezielt fremde IDs anfragen, in jede Testpipeline. Ein Penetrationstest mit manueller Komponente ergänzt das, ersetzt es aber nicht.

Reicht ein JWT-Guard in NestJS gegen Broken Access Control?

Nein. Ein Guard beantwortet, ob ein gültiger Token vorliegt, und optional, ob eine Rolle passt. Die Frage, ob der angefragte Datensatz dem Nutzer gehört, kann nur der Service beantworten, der den Datensatz kennt. Fehlt der Ownership-Check im Service, bleibt das Backend für IDOR offen, egal wie sauber die Authentifizierung ist. Die Dokumentation beschreibt Guards ausdrücklich als Entscheidung über den Zugang zur Route anhand von Laufzeitbedingungen, nicht als Prüfung einzelner Datensätze (NestJS Guards).

Warum zählt SSRF seit 2025 zu Broken Access Control?

OWASP hat SSRF 2021 als eigene Kategorie A10 eingeführt und 2025 in A01 integriert, weil die Datenbasis eine eigene Kategorie nicht mehr rechtfertigte und das Muster inhaltlich passt: Der Server überschreitet eine Zugriffsgrenze, die er nicht überschreiten dürfte, nur eben in Richtung interner Dienste statt in Richtung fremder Nutzerdaten. Für die Praxis ändert das nichts an den Gegenmaßnahmen, aber es rückt SSRF in den Fokus von Teams, die bisher nur Nutzerrechte geprüft haben.