API Security

API Security bezeichnet die Sicherheitsdisziplin rund um Programmierschnittstellen — typischerweise REST, GraphQL oder gRPC — über die moderne Anwendungen Daten und Funktionen exponieren. Während klassische Webanwendungen Geschäftslogik im Backend kapseln und nur HTML ausliefern, machen APIs diese Logik direkt zugänglich. Damit verlagert sich die Angriffsoberfläche: Authentifizierung, Autorisierung, Eingabevalidierung und Ressourcenkontrolle müssen für jede einzelne Schnittstelle sauber implementiert sein. Wir finden in Assessments regelmäßig, dass APIs deutlich schwächer abgesichert sind als die zugehörigen Web-Frontends, weil sie als reine Backend-Komponente unterschätzt werden.

OWASP API Security Top 10

Die OWASP API Security Top 10 in der Fassung von 2023 bilden den De-facto-Standard für API-spezifische Risiken. Die Liste unterscheidet sich bewusst von den klassischen Web-Top-10, weil APIs eigene Schwachstellenmuster haben — insbesondere im Bereich der Autorisierung auf Objekt- und Funktionsebene.

Broken Object Level Authorization (BOLA) ist in der Praxis das mit Abstand häufigste API-Risiko. Klassisches Beispiel: Ein Endpunkt /api/orders/{id} prüft zwar, dass der Aufrufer eingeloggt ist, aber nicht, ob die abgefragte Bestell-ID dem aufrufenden Benutzer gehört. Eine simple ID-Manipulation reicht, um fremde Daten abzugreifen. Solche Lücken lassen sich weder durch Firewalls noch durch klassische WAF-Regeln erkennen, weil die Requests syntaktisch korrekt sind — nur die Geschäftslogik wird verletzt.

Kernverteidigung: Authentifizierung und Autorisierung

Eine belastbare API-Authentifizierung basiert in modernen Architekturen auf OAuth 2.0 und OpenID Connect (OIDC). Clients erhalten kurzlebige Access-Tokens, die von einem zentralen Identity Provider ausgestellt werden. Für Service-zu-Service-Kommunikation hat sich mutual TLS (mTLS) etabliert — beide Seiten weisen ihre Identität über Client-Zertifikate nach, was deutlich robuster ist als statische API-Keys in Konfigurationsdateien.

Autorisierung muss konsequent zweistufig gedacht werden. Auf Funktionsebene wird geprüft, ob ein Aufrufer einen bestimmten Endpunkt überhaupt nutzen darf — das ist die klassische Rollenprüfung. Auf Objektebene wird zusätzlich verifiziert, ob das konkret angefragte Datenobjekt zum Aufrufer gehört oder von ihm gesehen werden darf. Diese Prüfung muss serverseitig erfolgen und darf sich niemals auf vom Client gelieferte Identifikatoren verlassen.

Schema-Validierung, Rate Limiting und Inventarisierung

Eine strikte Schema-Validierung gegen die OpenAPI- oder GraphQL-Definition fängt einen Großteil der Eingabeangriffe ab, bevor sie überhaupt die Geschäftslogik erreichen. Felder, die nicht im Schema stehen, werden abgewiesen — was zum Beispiel Mass-Assignment-Angriffe verhindert, bei denen ein Angreifer interne Felder wie isAdmin über den Request einschleust.

Rate Limiting muss pro Principal greifen, nicht pro IP-Adresse. Wer hunderte legitime Nutzer hinter einer Unternehmens-NAT sitzen hat, erkennt schnell, dass IP-basierte Limits entweder zu lax oder zu restriktiv sind. Sinnvoll sind gestaffelte Limits — etwa pro API-Key, pro Benutzer und pro Endpunkt — kombiniert mit Quotenfenstern für besonders teure Operationen.

Improper Inventory Management (API9) wird oft unterschätzt. In der Praxis finden sich auf produktiven Systemen regelmäßig veraltete API-Versionen, Test-Endpunkte oder Staging-APIs mit Produktionsdaten, die längst hätten abgeschaltet werden müssen. Ein gepflegtes API-Inventar mit klaren Lebenszyklus-Statusangaben (aktiv, deprecated, abgeschaltet) ist die Grundvoraussetzung für jedes weitere Security-Programm.

API-Gateways als zentraler Policy-Punkt

Statt jede einzelne API-Implementierung mit Sicherheitslogik anzureichern, lohnt sich der Einsatz eines API-Gateways als zentraler Durchsetzungspunkt. Gateways wie Kong, Apigee oder Cloudflare API Gateway übernehmen Authentifizierung, Token-Validierung, Rate Limiting, Schema-Enforcement und Logging einheitlich für alle Backend-Dienste. Das reduziert die Angriffsfläche erheblich, weil Sicherheitskontrollen nicht mehr in jedem Service neu implementiert werden — mit allen Inkonsistenzen, die das mit sich bringt.

KI-spezifische Angriffsfläche

LLM-Anwendungen erweitern das API-Security-Modell um neue Risikoklassen. Endpunkte, die Prompts entgegennehmen und an Sprachmodelle weiterreichen, sind anfällig für Prompt Injection, Model Extraction über systematische Abfragen und Datenabfluss über manipulierte Kontextfenster. Klassische Schema-Validierung greift hier nur eingeschränkt, weil der Eingabeinhalt natürlichsprachlich und damit grundsätzlich unstrukturiert ist.

Ein AI Gateway übernimmt für LLM-APIs die Rolle, die ein klassisches API-Gateway für REST-Schnittstellen spielt: zentrale Authentifizierung, Token-basierte Quotenkontrolle, Prompt- und Antwort-Filterung sowie Logging zur späteren Auswertung. Wir sehen in der Praxis, dass Organisationen ohne AI Gateway sehr schnell den Überblick über Modellnutzung, Kostenverteilung und Datenabflussrisiken verlieren.

Testverfahren in der Praxis

Automatisierte Tests sind für APIs deutlich ergiebiger als für klassische Webanwendungen, weil sich Schnittstellen aus dem OpenAPI-Schema direkt programmatisch ansprechen lassen. Contract Tests verifizieren, dass Implementierung und Spezifikation übereinstimmen. Fuzzing-Werkzeuge wie Schemathesis erzeugen automatisch tausende Varianten gültiger und ungültiger Requests aus dem Schema heraus und decken so Edge Cases auf, die manuelles Testen übersieht.

Für die manuelle Analyse sind Postman und die Burp Suite die etablierten Werkzeuge — Postman für Funktionstests und Workflows, Burp für die intercept-basierte Sicherheitsanalyse mit aktiver Manipulation. Ergänzend gehören DAST-Scanner (Dynamic Application Security Testing) und gezielte Penetration Tests in das Prüfportfolio. Wir empfehlen, BOLA- und Authorization-Szenarien immer manuell zu testen, weil sie sich automatisiert nur sehr eingeschränkt verlässlich abdecken lassen.

Relevanz für KMUs

Mittelständische Unternehmen exponieren heute über Partnerportale, Mobile Apps und Integrationen mit ERP- oder Buchhaltungssystemen oft mehr APIs als ihnen bewusst ist. Ein erster pragmatischer Schritt ist eine Bestandsaufnahme: Welche APIs existieren, wer authentifiziert sich wie, welche Daten fließen darüber? Auf dieser Basis lassen sich die OWASP API Top 10 als Prüfraster anwenden und gezielte Maßnahmen ableiten — etwa die Konsolidierung hinter einem API-Gateway, die Ablösung statischer API-Keys durch OAuth oder eine strukturierte Schwachstellenprüfung der wichtigsten Endpunkte. Gerade für KMUs ist der Hebel hoch, weil sich mit wenigen zentralen Maßnahmen ein Großteil der typischen API-Risiken adressieren lässt, ohne jede Anwendung einzeln umbauen zu müssen.