APIs erweitern die Angriffsfläche
APIs verbinden Webshops, Apps, Partner und interne Systeme. Sie verarbeiten häufig sensible Daten und geschäftskritische Aktionen. Gleichzeitig werden sie automatisiert aufgerufen und sind dadurch leicht in hoher Geschwindigkeit testbar. Ein einzelner Fehler in der Autorisierung kann deshalb sehr viele Datensätze betreffen.
Die OWASP API Security Top 10 beschreibt typische Risikoklassen wie fehlerhafte objektbezogene Autorisierung, unbeschränkten Ressourcenverbrauch und unsicheren Konsum externer APIs. Die Liste ersetzt kein eigenes Bedrohungsmodell, liefert aber eine gute Struktur für Reviews und Tests.
Authentifizierung und Autorisierung trennen
Authentifizierung beantwortet, wer ein Client ist. Autorisierung entscheidet, was dieser Client mit einem konkreten Objekt oder einer Funktion tun darf. Ein gültiges Token bedeutet nicht automatisch, dass der Benutzer jede Bestellung, jedes Kundenkonto oder jede administrative Aktion sehen darf.
Autorisierung muss bei jedem Zugriff serverseitig geprüft werden. Eine ausgeblendete Schaltfläche im Frontend ist keine Sicherheitskontrolle. Besonders kritisch sind Endpoints, die Objekt-IDs direkt entgegennehmen.
$order = $orderRepository->find($orderId);
if ($order === null) {
throw new NotFoundHttpException();
}
if ($order->customerId() !== $authenticatedCustomerId) {
throw new AccessDeniedHttpException();
}
return $order;BOLA und BFLA systematisch testen
Broken Object Level Authorization entsteht, wenn ein Benutzer durch Änderung einer ID auf fremde Objekte zugreifen kann. Broken Function Level Authorization betrifft Funktionen, die nur bestimmten Rollen zustehen. Beide Fehler lassen sich nicht allein durch Schema-Validierung verhindern.
- Objektzugriff immer gegen Identität und Mandant prüfen.
- Administrative Routen nicht nur durch Namenskonventionen schützen.
- Negative Tests für andere Benutzer und Rollen automatisieren.
- Interne IDs nicht als Schutzmechanismus betrachten.
- Berechtigungslogik zentral und wiederverwendbar implementieren.
Ressourcenverbrauch begrenzen
Eine gültige Anfrage kann trotzdem schädlich sein, wenn sie zu viel CPU, Speicher, Bandbreite oder externe Kosten verursacht. Große Seiten, komplexe Filter, teure Exporte und Passwort- oder SMS-Funktionen benötigen Grenzen.
Rate Limits sollten Identität, IP, Endpoint und fachliche Aktion berücksichtigen. Ein globales Limit schützt nicht vor einem einzelnen teuren Request. Zusätzlich gehören maximale Payload-, Batch- und Ergebnisgrößen in den Vertrag.
Sensible Geschäftsabläufe schützen
Nicht jede missbräuchliche Nutzung ist ein technischer Exploit. Ticketkäufe, Gutscheine, Reservierungen, Bewertungen oder Registrierungen können automatisiert werden. Schutzmaßnahmen müssen daher den fachlichen Schaden berücksichtigen.
- Geschwindigkeit und Volumen pro Identität begrenzen.
- Auffällige Muster erkennen und risikobasiert reagieren.
- Kritische Aktionen mit zusätzlicher Bestätigung absichern.
- Automatisierung nicht nur über Captchas bekämpfen.
- Missbrauchssignale protokollieren, ohne unnötige personenbezogene Daten zu sammeln.
SSRF und externe APIs
Wenn eine API URLs oder Hostnamen aus Nutzereingaben abruft, kann Server-Side Request Forgery entstehen. Ein Angreifer versucht dabei, interne Dienste, Metadaten-Endpunkte oder unerwartete Ziele durch den Server aufrufen zu lassen.
Ziele sollten über Allow-Lists begrenzt, DNS-Auflösung kontrolliert und Weiterleitungen erneut geprüft werden. Private Netze und lokale Adressen müssen blockiert werden. Antworten externer APIs sind grundsätzlich nicht vertrauenswürdiger als Nutzereingaben und benötigen dieselbe Validierung.
API-Inventar und Versionen pflegen
Veraltete Endpoints, Testsysteme und Debug-Routen bleiben häufig länger erreichbar als geplant. Ein vollständiges Inventar dokumentiert Hosts, Versionen, Eigentümer, Datenarten und Abschalttermine. Gateways und Logs können zeigen, ob alte Versionen noch verwendet werden.
Sichere Standardeinstellungen
- Nur notwendige Datenfelder ausgeben.
- Fehlermeldungen ohne interne Details liefern.
- CORS und erlaubte Methoden restriktiv konfigurieren.
- Token kurzlebig und zielgebunden ausstellen.
- Secrets nicht in URLs, Logs oder Client-Code speichern.
- Abhängigkeiten und Laufzeiten regelmäßig aktualisieren.
Fazit
API-Sicherheit entsteht aus konsequenter Autorisierung, kontrolliertem Ressourcenverbrauch und einem vollständigen Überblick über alle Endpoints. Automatisierte Tests, Monitoring und ein eigenes Bedrohungsmodell machen Sicherheitskontrollen wiederholbar. So wird Schutz Teil der Entwicklung statt einer einmaligen Prüfung vor dem Go-live.
