API-Sicherheit.

API-Sicherheit umfasst REST-, GraphQL-, gRPC- und Webhook-Oberflächen, die häufig Geschäftslogik direkt exponieren. Sie orientiert sich an den OWASP API Security Top 10 (2023), die Broken Object Level Authorization (BOLA/API1) an erster Stelle führen, gefolgt von Broken Authentication, Broken Object Property Level Authorization, ungebremstem Ressourcenverbrauch, Broken Function Level Authorization und SSRF.

Warum BOLA dominiert. Die meisten API-Breaches sind nicht exotisch – es fehlen Besitzprüfungen je Objekt. Beim Optus-Breach (September 2022) verlangte ein aus dem Internet erreichbarer Endpoint keine Authentifizierung und exponierte über fortlaufende IDs adressierbare Datensätze, sodass rund 10 Millionen Australier enumeriert werden konnten. Im Januar 2023 meldete T-Mobile den Missbrauch einer API, die die Sitzung zwar authentifizierte, aber nicht einschränkte, welche Datensätze sie lesen durfte – etwa 37 Millionen Konten waren betroffen. Beides sind Lehrbuchfälle fehlender Objektebenen-Autorisierung.

Kontrollen. Wirksame Programme kombinieren starke Identität (OAuth 2.0/OIDC, kurzlebige scope-basierte Tokens, mTLS), eine serverseitige Besitzprüfung bei jeder Objektreferenz, schemabasierte Request-/Response-Validierung, Rate-Limiting und Quoten gegen Scraping sowie strukturiertes Logging in ein SIEM. Kontinuierliche Tests via SAST, DAST und API-spezifischem Fuzzing fangen Regressionen ab. Discovery und Inventar von Shadow- und Zombie-APIs sind Grundlage – verteidigen lässt sich nur, was bekannt ist.

flowchart TD
  A[Client-Request + Bearer-Token] --> B{Token gültig?}
  B -->|Nein| R[401 Unauthorized]
  B -->|Ja| C{Erlaubt der Scope diese Operation?}
  C -->|Nein| F[403 Forbidden]
  C -->|Ja| D{Gehört die Objekt-ID dem Aufrufer?}
  D -->|Nein - BOLA-Risiko| F
  D -->|Ja| E{Innerhalb Limit und Schema gültig?}
  E -->|Nein| G[429 / 400 abgelehnt]
  E -->|Ja| H[Nur erlaubte Felder zurückgeben]