Broken Access Control Teil 4 – Schutzmaßnahmen und Best Practices

Sep. 12, 2025

—

von

in Broken-Access-Control, Cyber Security, Websecurity

Das Fundament: Zugriffskontrolle ernst nehmen

Broken Access Control (BAC) zählt nicht umsonst zu den gefährlichsten Schwachstellen in den OWASP Top 10. Die gute Nachricht: Mit klaren Regeln und Best Practices lassen sich die meisten Probleme vermeiden. Entscheidend ist, Zugriffskontrolle als zentrales Thema in der Architektur zu behandeln, nicht als nachträgliches Detail.

Autorisierung auf Server-Seite

Die wichtigste Regel lautet: Nie auf den Client verlassen.
Ob URLs, versteckte Formularfelder oder JavaScript-Variablen – alles, was vom Client kommt, kann manipuliert werden.

Beispiel für eine unsichere API:

// unsicher
app.get('/api/user/:id', (req, res) => {
  const user = db.findUser(req.params.id);
  res.json(user); // liefert jeden Datensatz zurück
});

Sichere Variante:

// sicher
app.get('/api/user/:id', (req, res) => {
  const user = db.findUser(req.params.id);
  if (user.id !== req.authenticatedUser.id) {
    return res.status(403).send('Access denied');
  }
  res.json(user);
});

Damit wird serverseitig geprüft, ob der eingeloggte Nutzer Zugriff auf genau dieses Objekt hat.

Principle of Least Privilege

Ein Grundsatz der IT-Sicherheit: Jeder Nutzer sollte nur die Rechte bekommen, die er unbedingt braucht.

Normale User: Zugriff nur auf eigene Daten.
Support: Zugriff auf bestimmte Daten, aber nicht auf Admin-Funktionen.
Admins: Zugriff auf alles – aber nur, wenn nötig.

So reduziert man die Angriffsfläche erheblich.

Rollen- und Rechtekonzepte umsetzen

Ein robustes Role-Based Access Control (RBAC)-System ist Pflicht. Viele Frameworks bringen das schon mit:

Spring Security (Java) → Annotations wie @PreAuthorize("hasRole('ADMIN')").
Laravel Policies (PHP) → Regeln definieren, welche Aktionen erlaubt sind.
Django Permissions (Python) → granular pro Modell oder Objekt.

Noch flexibler ist Attribute-Based Access Control (ABAC): Zugriff wird anhand von Attributen entschieden, z. B. „Nutzer gehört zur gleichen Abteilung wie das Dokument“.

Sensible Endpunkte absichern

Admin-Seiten sollten hinter einer Login-Barriere liegen und zusätzlich rollenbasiert geschützt sein.
HTTP-Methoden müssen restriktiv behandelt werden: Wenn DELETE oder PUT nicht erlaubt ist, sollte der Server diese Requests klar blocken.
Statische Ressourcen wie Backups oder Konfigurationsdateien dürfen nicht direkt im Webroot liegen.

Opaque IDs und Defense-in-Depth

Vorhersehbare IDs wie 1001, 1002 erleichtern Angriffe.
Besser: UUIDs oder zufällige Tokens.

Aber: Das ersetzt keine Autorisierung, sondern ist nur ein zusätzlicher Schutz.
„Defense in Depth“ bedeutet: mehrere Schutzschichten kombinieren – damit ein Fehler nicht sofort zum Totalausfall führt.

Logging und Monitoring

Auch mit guter Zugriffskontrolle können Angreifer versuchen, BAC auszunutzen. Daher ist Überwachung wichtig:

Ungewöhnliche Muster erkennen (z. B. viele Zugriffe auf unterschiedliche IDs).
403-Fehler im Auge behalten – sie können auf Angriffsversuche hindeuten.
Alerts konfigurieren, wenn auffällige Aktionen passieren.

So lassen sich Angriffe frühzeitig entdecken.

Typische Fehler vermeiden

Nur Login prüfen: „Eingeloggt = alles erlaubt.“ → Unsicher.
Nur UI-Schutz: Buttons im Frontend verstecken reicht nicht.
Falsche Annahmen: „UUIDs machen uns sicher.“ → Nicht ohne echte Autorisierung.

Was du mitnehmen solltest

Zugriffskontrolle gehört in die Serverlogik, nicht ins Frontend.
Rollen- und Rechtekonzepte sind Pflicht – am besten mit Framework-Support.
Das „Least Privilege“-Prinzip reduziert Risiken erheblich.
Opaque IDs, Logging und Monitoring runden die Verteidigung ab.

Im nächsten Teil der Serie werfen wir einen Blick nach vorn: Welche Missverständnisse gibt es rund um Broken Access Control, wie hängt es mit anderen Schwachstellen zusammen – und wo kann man weiter lernen und üben?