API-Security: der blinde Fleck hinter jeder Integration

7 Min. Lesezeit

Das Frontend ist gehärtet, der Login sitzt, die Firewall steht. Und dann ruft eine Mobile-App eine Schnittstelle auf, die jede Bestellung jedes Kunden ausliefert, sobald man die Nummer im Request um eins hochzählt. Kein Exploit-Tool, kein Zero-Day, nur eine fehlende Prüfung. Genau dort, in den APIs hinter den sichtbaren Apps, ist die Angriffsfläche in den letzten Jahren hingewandert. Und sie ist oft schlechter geschützt als das, was vorne steht.

Verwandt:Geteilter Kernel als Lücke: Wie Container-Ausbrüche gelingen  /  14 bösartige npm-Pakete in 4 Stunden: Statik reicht nicht

Warum die Angriffsfläche hinter die App gewandert ist

Vor zehn Jahren war die Webseite das Tor. Heute ist die Webseite nur noch die Fassade, dahinter arbeiten Schnittstellen. Die Mobile-App spricht mit einer API, das Partnerportal zieht Daten über eine API, das ERP synchronisiert über eine API, und der KI-Assistent, den gerade jemand eingebaut hat, ruft auch eine API. Jede dieser Verbindungen ist eine Tür, durch die Daten ein- und ausgehen.

Das Unbequeme daran: Diese Türen sind unsichtbarer als die Eingangsseite. Ein Pentest klopft die Webanwendung ab, ein API-Endpunkt, der nur von einer App genutzt wird, fällt leicht durchs Raster. Genau hier verlasse ich mich nicht auf das Gefühl, alles im Blick zu haben. Ich habe öfter, als mir lieb ist, eine API gefunden, von der das Team schwor, es gebe sie gar nicht mehr.

BOLA und die OWASP-Liste: wo es konkret bricht

Was ist API-Security? API-Security umfasst die Maßnahmen, die eine Programmierschnittstelle vor Missbrauch schützen: korrekte Authentifizierung, Autorisierung auf Objekt- und Funktionsebene, Begrenzung der Last und Prüfung der übergebenen Daten. Sie unterscheidet sich von klassischer Web-Sicherheit, weil bei einer API jeder Aufruf direkt die Geschäftslogik trifft, ohne schützende Oberfläche davor.

Die OWASP API Security Top 10 sind die nützlichste Landkarte für die Schwachstellen, die in der Praxis wirklich auftauchen. Ganz oben steht BOLA, Broken Object Level Authorization. Der Server prüft, ob jemand angemeldet ist, aber nicht, ob ihm das angefragte Objekt auch gehört. Ein Aufruf von /api/orders/1043 liefert die eigene Bestellung, der Aufruf von /api/orders/1044 die eines Fremden. Kein Werkzeug nötig, ein Zähler reicht.

Direkt daneben liegen kaputte Authentifizierung, bei der Token zu lange leben oder zu lasch geprüft werden, und unbegrenzter Ressourcenverbrauch, bei dem ein einziger Client mit ungebremsten Anfragen die Schnittstelle in die Knie zwingt. Keine dieser Lücken ist exotisch. Sie entstehen, weil eine API schnell gebaut wurde, um eine App zu bedienen, und die Sicherheitsfragen auf später vertagt wurden. Dieses Später kam in der Praxis selten.

Shadow-APIs: man schützt nur, was man kennt

Das größte Problem ist selten die Schnittstelle, über die alle reden, sondern die, an die sich niemand erinnert. Shadow-APIs entstehen, wenn ein Team schnell einen Endpunkt baut und ihn nie in die offizielle Dokumentation nimmt. Zombie-APIs sind alte Versionen, die nach einem Release laufen blieben, weil sie ja niemandem wehtun. Beide sind ungepatcht, ungeprüft und oft ohne aktuelle Zugriffsregeln unterwegs.

Deshalb beginnt API-Sicherheit nicht mit einem Tool, sondern mit einer Liste. Wer seine Endpunkte nicht kennt, kann sie nicht absichern, nicht überwachen und nicht abschalten. Das klingt banal, ist aber der Schritt, den die meisten überspringen, weil er nach Fleißarbeit aussieht. Ohne diese Fleißarbeit bleibt der Rest Kosmetik.

Fünf Schritte, die den Großteil tragen

Die gute Nachricht für den Mittelstand: API-Sicherheit verlangt selten eine teure neue Appliance. Sie verlangt, ein paar Dinge konsequent zu tun. Diese fünf Schritte tragen den größten Teil der Last.

1. Inventar führen. Jeden Endpunkt erfassen, inklusive der alten und der inoffiziellen. Ein Gateway oder ein einfacher Scan macht sichtbar, was tatsächlich erreichbar ist.
2. Autorisierung pro Objekt prüfen. Bei jedem Aufruf nicht nur fragen, ob jemand angemeldet ist, sondern ob ihm das angefragte Objekt gehört. Das ist die direkte Antwort auf BOLA.
3. Authentifizierung am Gateway bündeln. Token-Prüfung, Ablaufzeiten und Scopes zentral durchsetzen, statt sie in jeder Anwendung neu und fehleranfällig zu bauen.
4. Rate-Limiting setzen. Eine Obergrenze pro Client erschwert das schnelle Durchprobieren von IDs und fängt Überlast durch einen einzelnen Aufrufer ab. Den eigentlichen BOLA-Fix liefert weiter die Objekt-Autorisierung aus Schritt zwei.
5. Eingaben am Schema validieren. Was nicht der erwarteten Struktur entspricht, wird abgewiesen, bevor es die Geschäftslogik erreicht.

Nichts davon ist neu, und genau das ist der Punkt. Die Lücken in APIs entstehen nicht, weil das Wissen fehlt, sondern weil die Schnittstelle unter Zeitdruck gebaut und die Absicherung vertagt wurde. Diese Konfiguration einmal sauber als Standard zu setzen, ist günstiger als der erste Vorfall, bei dem jemand die Bestellungen der gesamten Kundschaft abgezogen hat.

Der erste Schritt ohne Security-Team

Wer kein Security-Team hat, fängt nicht mit dem teuersten Werkzeug an, sondern mit der unbequemsten Frage: Welche Schnittstellen haben wir überhaupt, und wer darf darüber an welche Daten? Die Antwort darauf deckt erfahrungsgemäß mehr auf als jeder gekaufte Scanner. Ein API-Gateway, das viele Cloud-Anbieter ohnehin mitliefern, bündelt Authentifizierung, Rate-Limiting und Logging an einer Stelle und macht aus verstreuten Türen einen kontrollierten Eingang.

Der Rest ist Haltung. Eine Schnittstelle ist erst fertig, wenn jemand entschieden hat, wer sie aufrufen darf und was passiert, wenn jemand es zu oft tut. Solange diese Entscheidung fehlt, ist die API kein Produkt, sondern ein offenes Fenster, das nur noch niemand gefunden hat.

Häufige Fragen

Was unterscheidet API-Security von klassischer Web-Sicherheit?

Klassische Web-Sicherheit schützt eine Oberfläche, hinter der die Logik liegt. Eine API hat keine Oberfläche, jeder Aufruf trifft direkt die Logik. Deshalb reicht eine WAF nicht aus, die eigentliche Kontrolle, vor allem die Autorisierung pro Objekt, muss in der Anwendung selbst sitzen.

Was ist BOLA und warum ist es so verbreitet?

BOLA steht für Broken Object Level Authorization. Der Server prüft, ob ein Nutzer angemeldet ist, aber nicht, ob ihm das angefragte Objekt gehört. Wer eine ID im Request hochzählt, sieht fremde Daten. Es ist verbreitet, weil die Prüfung leicht vergessen wird, wenn eine API schnell für eine App gebaut wird.

Brauche ich ein teures API-Security-Tool?

Für den Anfang nicht. Ein API-Inventar, Autorisierung pro Objekt, ein Gateway für Authentifizierung und Rate-Limiting sowie Schema-Validierung decken den größten Teil ab. Spezialisierte Werkzeuge helfen beim Skalieren und beim Aufspüren von Shadow-APIs, sind aber kein Ersatz für die Grundlagen.

Was sind Shadow- und Zombie-APIs?

Shadow-APIs sind Endpunkte, die gebaut, aber nie dokumentiert wurden. Zombie-APIs sind alte Versionen, die nach einem Release weiterlaufen. Beide entziehen sich der Überwachung und tragen oft veraltete Zugriffsregeln. Sie sind ein Hauptgrund, warum ein vollständiges Inventar der erste Schritt ist.

Wo sollte ein Mittelständler ohne Security-Team anfangen?

Bei der Bestandsaufnahme: Welche Schnittstellen existieren, und wer darf über sie an welche Daten? Danach ein API-Gateway nutzen, das viele Cloud-Anbieter mitliefern, um Authentifizierung, Rate-Limiting und Logging zentral zu bündeln. Das ist günstiger und wirksamer als ein gekaufter Scanner ohne Grundlagen.

Lesetipps der Redaktion

• PAM ohne Enterprise-Budget: Admin-Rechte im Griff
• Passkeys im Mittelstand: das Ende des Passworts
• Patch-Priorisierung: Warum CVSS allein dein SOC bremst

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (Juni 2026), C2PA-Zertifikat im Bild hinterlegt

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor Alec Chizhik