Wie würdest du eine öffentlich erreichbare REST-API absichern?

Eine API abzusichern bedeutet zu kontrollieren, wer sie aufrufen darf, was sie tun dürfen und was sie senden dürfen – bei jeder einzelnen Anfrage, denn eine API ist zustandslos und jede Anfrage muss für sich allein bestehen.

Authentifizierung vs. Autorisierung

Beide sind verschieden und beide erforderlich. Authentifizierung weist nach, wer der Aufrufer ist – typischerweise ein kurzlebiges Bearer-Token aus OAuth2/OIDC, das bei jeder Anfrage validiert wird (Signatur, Ablauf, Audience). Autorisierung entscheidet, was dieser authentifizierte Aufrufer tun darf. Der häufigste und schädlichste API-Fehler ist die gebrochene objektbezogene Autorisierung (BOLA/IDOR): Der Code authentifiziert den Benutzer, gibt dann aber das Objekt /orders/123 zurück, ohne zu prüfen, ob Bestellung 123 ihm tatsächlich gehört. Verifiziere stets die Eigentümerschaft der konkreten Ressource, nicht nur, dass jemand angemeldet ist.

Transport und Eingaben

• TLS überall – akzeptiere niemals Klartext und packe keine Secrets oder Tokens in Query-Strings, wo sie in Logs landen.
• Validiere und begrenze Eingaben serverseitig gegen ein striktes Schema; weise unerwartete Felder und übergroße Payloads zurück. Vertraue niemals der clientseitigen Validierung.
• Parametrisiere Abfragen und kodiere die Ausgabe, um Injektionen zu blockieren.

Missbrauch und Sichtbarkeit

• Rate Limiting und Kontingente schützen vor Brute Force, Scraping und Denial of Service; stelle sie für authentifizierte vs. anonyme Aufrufer unterschiedlich ein.
• Logging und Monitoring von Auth-Fehlern und anomalen Zugriffsmustern lassen dich laufende Angriffe erkennen.
• Minimiere die Datenoffenlegung – gib nur die Felder zurück, die der Client braucht, damit die API über zu weit gefasste Antworten keine internen Daten preisgibt.

Worauf Interviewer achten

Kandidaten, die nur »API-Schlüssel verwenden« sagen, verfehlen den Kern. Die starke Antwort trennt Authentifizierung von Autorisierung, benennt objektbezogene Zugriffsprüfungen (BOLA/IDOR) als oberstes reales Risiko und rundet das Ganze mit TLS, Eingabevalidierung und Rate Limiting ab.