Was ist eine API?

API steht für Application Programming Interface, also Programmierschnittstelle. Eine API legt fest, wie Anwendungen Daten abfragen, Funktionen auslösen und Ergebnisse austauschen. Sie bildet damit die kontrollierte Grenze zwischen einem Anbieter und seinen Clients - etwa einer mobilen App, einem Web-Frontend, einem Partnerdienst oder einem internen System.

Wie funktioniert eine API?

Häufig verwendet eine API das Client-Server-Modell: Der Client sendet eine Anfrage an einen definierten Endpunkt. Die Anfrage enthält eine Methode, Parameter, Header und gegebenenfalls einen Body. Der Server prüft Identität, Berechtigung und Eingaben, verarbeitet die Aktion und antwortet mit Daten sowie einem Statuscode.

GET /api/orders/4711 HTTP/1.1
Host: example.test
Authorization: Bearer <access-token>
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"id":4711,"status":"processing"}

Ein technisch gültiges Token allein reicht nicht. Der Server muss zusätzlich prüfen, ob die angemeldete Identität genau diese Bestellung lesen darf. Fehlt diese objektbezogene Autorisierung, entsteht häufig eine IDOR-Schwachstelle.

Welche API-Arten gibt es?

Die Wahl beeinflusst Datenmodell, Fehlerbehandlung und Sicherheitskontrollen. Die speziellen Risiken bidirektionaler Verbindungen erläutert der Artikel über WebSockets; Abfragen und Resolver werden im GraphQL-Artikel behandelt.

Authentifizierung und Autorisierung

Authentifizierung beantwortet, wer anfragt. Autorisierung entscheidet für jede Operation und jedes Objekt, was diese Identität tun darf. API-Keys identifizieren häufig eine Anwendung, sind aber nicht automatisch für Benutzeranmeldung oder feingranulare Rechte geeignet. Für delegierten Zugriff werden oft OAuth 2.0 und OpenID Connect eingesetzt. Dabei müssen Zugriffstoken - häufig JSON Web Tokens - hinsichtlich Signatur, Aussteller, Zielgruppe, Gültigkeit und vorgesehenem Zweck geprüft werden.

Welche API-Schwachstellen sind besonders wichtig?

Wie wird eine API sicher entworfen?

1. Inventar und Vertrag:
   Endpunkte, Versionen, Eigentümer, Datenklassen und Abhängigkeiten dokumentieren. Nicht dokumentierte und alte Versionen ebenfalls erfassen.
2. Explizite Eingaben:
   Erlaubte Felder, Typen, Wertebereiche und Objektgrößen serverseitig validieren; unbekannte Eigenschaften ablehnen.
3. Autorisierung je Aktion:
   Rolle, Mandant, Objektbeziehung und Statusübergang für jeden Request prüfen - nicht nur beim Login.
4. Begrenzung:
   Rate, Parallelität, Abfragetiefe, Seitengröße, Uploads und Laufzeit passend zum Endpunkt begrenzen.
5. Sichere Ausgabe:
   Nur notwendige Felder zurückgeben, Fehler ohne interne Details ausliefern und sensible Antworten nicht unkontrolliert cachen.
6. Überwachung:
   Fehlgeschlagene Autorisierung, ungewöhnliche Objektzugriffe und hohe Fehlerraten mit einer Request-ID nachvollziehbar protokollieren - ohne Tokens oder unnötige personenbezogene Daten.

Dokumentation, Versionierung und Tests

OpenAPI beschreibt REST-nahe Schnittstellen maschinenlesbar; bei GraphQL übernimmt das Schema einen Teil dieser Rolle. Eine Dokumentation sollte Authentifizierung, Fehler, Limits, Datenmodelle und Beispiele enthalten, aber keine produktiven Zugangsdaten. Änderungen benötigen eine klare Kompatibilitäts- und Abschaltstrategie. Sicherheitsprüfungen kombinieren Vertragsanalyse, Quellcodeprüfung und manuelle Tests mit verschiedenen Rollen und Mandanten. Automatische Scanner finden bekannte Muster, verstehen jedoch selten vollständig, ob ein Geschäftsprozess fachlich missbraucht werden kann.