Broken Access Control

Was ist Broken Access Control?

Broken Access Control bezeichnet eine Sicherheitslücke, bei der eine Anwendung Zugriffsrechte unvollständig oder fehlerhaft prüft. Dadurch können Nutzer Daten lesen, verändern oder Funktionen ausführen, für die ihnen die erforderliche Berechtigung fehlt. Betroffen sein können einzelne Datensätze, Benutzerkonten, Verwaltungsbereiche und Programmierschnittstellen.

Broken Access Control, auf Deutsch einmalig als fehlerhafte Zugriffskontrolle bezeichnet, entsteht, wenn eine Anwendung Berechtigungen nicht bei jeder geschützten Aktion serverseitig kontrolliert. Ein angemeldeter Nutzer kann dann möglicherweise fremde Bestellungen öffnen, interne Dateien abrufen oder Verwaltungsfunktionen ausführen.

Wie Broken Access Control entsteht

Eine Anwendung muss bei jeder Anfrage drei Punkte prüfen: Wer stellt die Anfrage, welche Ressource soll erreicht werden und ist die angeforderte Aktion für diesen Nutzer erlaubt? Broken Access Control liegt vor, sobald eine dieser Prüfungen fehlt, zu allgemein ausfällt oder nur in der Benutzeroberfläche stattfindet.

Das Ausblenden eines Buttons ist keine Zugriffskontrolle. Ein Nutzer kann die dahinterliegende URL oder API-Anfrage weiterhin direkt aufrufen. Die Berechtigungsprüfung gehört deshalb auf den Server und muss unabhängig davon greifen, ob die Anfrage über einen Browser, eine App oder ein selbst erstelltes Skript eingeht.

Direkter Zugriff auf fremde Datensätze

Ein typischer Fall ist die sogenannte Insecure Direct Object Reference, kurz IDOR. Ruft ein Kunde beispielsweise /rechnung/4711 auf und ändert die Nummer auf 4712, darf die Anwendung die zweite Rechnung nur ausliefern, wenn sie demselben Kunden gehört. Eine erfolgreiche Anmeldung allein reicht für diese Entscheidung nicht aus.

Manipulierte Rollen und Parameter

Broken Access Control kann auch entstehen, wenn Rollen oder Berechtigungen aus veränderbaren Eingaben übernommen werden. Werte wie role=admin, eine Benutzer-ID in einem Formular oder ein manipulierbares Cookie dürfen keine alleinige Grundlage für die Freigabe geschützter Funktionen bilden. Der Server muss Rollen aus einer vertrauenswürdigen Sitzung oder Datenquelle ableiten.

Formen von Broken Access Control

Die Richtung der unzulässigen Rechteausweitung bestimmt, welche Form von Broken Access Control vorliegt. Für Sicherheitstests ist diese Unterscheidung hilfreich, weil horizontale und vertikale Angriffe unterschiedliche Prüfpfade benötigen.

Horizontaler Zugriff: Ein Nutzer erreicht Daten eines anderen Nutzers mit derselben Berechtigungsstufe, etwa dessen Rechnungen, Nachrichten oder Profildaten.
Vertikale Rechteausweitung: Ein normaler Nutzer erhält Zugriff auf Funktionen einer höheren Rolle, beispielsweise Benutzerverwaltung, Exporte oder Systemeinstellungen.
Kontextabhängiger Zugriff: Eine grundsätzlich erlaubte Aktion wird außerhalb des vorgesehenen Ablaufs ausgeführt, etwa eine Stornierung nach abgeschlossener Abrechnung.
Unautorisierter API-Zugriff: Eine Programmierschnittstelle prüft Anmeldung, Objektzugehörigkeit oder erlaubte Aktionen nicht bei jedem Endpunkt.

Authentifizierung und Autorisierung

Der Unterschied zwischen Authentifizierung und Broken Access Control liegt in der geprüften Frage. Die Authentifizierung stellt fest, wer ein Nutzer ist. Die Autorisierung legt fest, was dieser Nutzer tun darf. Ein System kann die Identität korrekt bestätigen und trotzdem fremde Daten ausliefern, wenn anschließend die Berechtigungsprüfung fehlt.

Auch die HTTP-Statuscodes unterscheiden beide Situationen. Eine nicht oder nicht mehr authentifizierte Anfrage wird üblicherweise mit 401 Unauthorized beantwortet. Ist die Identität bekannt, aber die Aktion nicht erlaubt, passt 403 Forbidden. Eine Anwendung kann bei sensiblen Ressourcen stattdessen 404 Not Found verwenden, damit deren Existenz nicht offengelegt wird.

Eine geschützte URL ist nicht sicher, nur weil sie schwer zu erraten ist oder in keinem Menü erscheint. Fortlaufende IDs, Dateinamen und API-Endpunkte lassen sich systematisch testen. Jede Anfrage benötigt eine serverseitige Prüfung von Identität, Rolle, Ressource und erlaubter Aktion.

So verhinderst du Broken Access Control

Eine belastbare Zugriffskontrolle folgt dem Prinzip Deny by Default: Ohne ausdrücklich erteilte Berechtigung wird eine Anfrage abgelehnt. Diese Regel verhindert, dass neue Seiten, API-Endpunkte oder Funktionen versehentlich öffentlich erreichbar werden, weil ein Entwickler keine spezielle Sperre ergänzt hat.

Rollenbasierte Zugriffskontrolle, kurz RBAC, ordnet Berechtigungen festen Rollen wie Kunde, Redakteur oder Administrator zu. Bei objektbezogenen Daten reicht RBAC jedoch nicht aus. Ein Kunde darf zwar grundsätzlich Rechnungen lesen, aber ausschließlich Rechnungen, die seinem Konto zugeordnet sind. Die Rollenprüfung muss deshalb um eine Eigentumsprüfung ergänzt werden.

Berechtigungen zentral definieren und nicht über zahlreiche Controller, Templates oder API-Endpunkte verteilen.
Jede Lese-, Schreib-, Lösch- und Exportaktion separat autorisieren.
Objektzugehörigkeit serverseitig aus der Sitzung und der Datenbank prüfen.
Verwaltungsbereiche, Dateien, APIs und Hintergrundfunktionen in die Tests einbeziehen.
Abgelehnte Zugriffe protokollieren und ungewöhnliche Serien von Anfragen überwachen.
Automatisierte Tests für verschiedene Rollen und fremde Objekt-IDs in die Entwicklung integrieren.

Broken Access Control testen

Ein sinnvoller Test arbeitet mit mindestens zwei normalen Konten und einer höher privilegierten Rolle. Der Prüfer ruft mit Konto A einen eigenen Datensatz auf, übernimmt die Anfrage und ersetzt anschließend die Objekt-ID durch einen Datensatz von Konto B. Danach wird geprüft, ob Lese-, Änderungs-, Lösch- und Exportanfragen zuverlässig abgelehnt werden.

Automatisierte Scanner können auffällige Endpunkte, Parameter und Statuscodes finden, aber die fachliche Berechtigung oft nicht vollständig beurteilen. Ein Scanner weiß beispielsweise nicht automatisch, ob ein Vertriebsmitarbeiter Angebote einer anderen Region sehen darf. Broken Access Control erfordert deshalb technische Tests und eine dokumentierte Berechtigungsmatrix mit Rollen, Ressourcen und Aktionen.

Folgen für SEO, SEA und GEO

Broken Access Control ist kein direkter Ranking-Faktor. Ein erfolgreicher Angriff kann jedoch indexierbare Spam-Seiten, unerwünschte Weiterleitungen, veränderte Inhalte oder Serverausfälle verursachen. Solche Folgen beeinträchtigen Crawling, Indexierung, organischen Traffic und das Vertrauen in die Domain. Ein SEO-Audit kann technische Auswirkungen erkennen, ersetzt aber keinen Sicherheitstest der Berechtigungslogik.

Für SEA können manipulierte Landingpages Anzeigenziele unbrauchbar machen oder Nutzer auf fremde Angebote leiten. Bei GEO, der Generative Engine Optimization, können veränderte Inhalte zudem falsche Unternehmensinformationen an Suchmaschinen und KI-Systeme liefern. Nach einem Sicherheitsvorfall sollten Marketing und IT deshalb Inhalte, Weiterleitungen, Indexierungsstatus und Tracking gemeinsam kontrollieren.

Bereits beim Aufbau oder Relaunch einer Website sollten Rollen, Kundenbereiche und Schnittstellen in die technische Planung aufgenommen werden. Eine professionell geplante Website verbindet dabei Informationsarchitektur, Suchmaschinenanforderungen und klare Zugriffsregeln. Ergänzend deckt ein technischer SEO-Check öffentlich erkennbare Website-Probleme auf, prüft aber keine internen Benutzerrechte.

Häufige Fragen zu Broken Access Control

Ist Broken Access Control dasselbe wie ein fehlender Login?

Nein. Ein fehlender Login ist nur eine mögliche Ursache. Broken Access Control betrifft auch angemeldete Nutzer, die auf fremde Daten oder Funktionen außerhalb ihrer Rolle zugreifen können.

Was ist ein einfaches Beispiel für Broken Access Control?

Ein Kunde ändert die Rechnungsnummer in einer URL und kann dadurch die Rechnung eines anderen Kunden öffnen. Die Anwendung hat den Nutzer zwar angemeldet, aber die Zuordnung der Rechnung zum Benutzerkonto nicht geprüft.

Kann eine Website trotz HTTPS betroffen sein?

Ja. HTTPS verschlüsselt die Verbindung zwischen Browser und Server, entscheidet aber nicht über Benutzerrechte. Eine verschlüsselte Anfrage kann weiterhin unzulässig sein, wenn die Anwendung keine korrekte Autorisierung durchführt.

Reicht eine schwer zu erratende URL als Schutz?

Nein. Unbekannte oder komplexe URLs ersetzen keine Zugriffskontrolle. Der Server muss jede Anfrage prüfen, auch wenn die Adresse nicht verlinkt oder nur eingeloggten Nutzern bekannt ist.

Können automatische Sicherheitsscanner die Schwachstelle finden?

Scanner können verdächtige Parameter und Endpunkte erkennen. Ob ein bestimmter Nutzer fachlich auf einen Datensatz zugreifen darf, lässt sich jedoch oft nur mit mehreren Testkonten und einer Berechtigungsmatrix zuverlässig prüfen.

Was sollte nach einem gefundenen Berechtigungsfehler passieren?

Der betroffene Zugriff muss serverseitig geschlossen und für vergleichbare Endpunkte geprüft werden. Zusätzlich sollten Protokolle ausgewertet, möglicherweise offengelegte Daten ermittelt, Zugangsdaten bei Bedarf erneuert und automatisierte Regressionstests ergänzt werden.

Wenn ein Sicherheitsvorfall bereits Crawling, Inhalte oder Indexierung beeinflusst, sollte die Domain technisch und aus SEO-Sicht geprüft werden. Ein Potenzialcheck ordnet die sichtbaren Folgen ein und zeigt, welche Maßnahmen mit der IT abgestimmt werden müssen.

Kostenlosen Potenzialcheck anfragen

Sie haben noch Fragen?

Kontaktieren Sie uns