In den letzten Jahren hat die zunehmende Verbreitung von APIs die Arbeitsweise von Unternehmen grundlegend verändert. APIs ermöglichen es verschiedenen Anwendungen, miteinander zu kommunizieren und Daten auszutauschen, wodurch Geschäftsprozesse und Softwareentwicklung effizienter und effektiver gestaltet werden können.
Mit der zunehmenden Nutzung von APIs steigt jedoch auch das Risiko einer API-Wildwuchs, bei der APIs über verteilte Teams und Architekturen hinweg erstellt und bereitgestellt werden – häufig ohne angemessene Kontrolle und Verwaltung. Dadurch können neue Sicherheitsrisiken für Unternehmen entstehen, da jede API einen potenziellen Einstiegspunkt für Angreifer darstellt, über den sie sich unbefugten Zugriff auf sensible Daten und Systeme verschaffen können.
Der Aufstieg der API-First-Softwareentwicklung
Einer der Hauptgründe für die unkontrollierte Ausbreitung von APIs ist die zunehmende Verbreitung von Microservices. Eine Microservices-Architektur unterteilt eine größere Anwendung in kleinere, eigenständige Anwendungen, die über APIs miteinander kommunizieren. Dadurch werden komplexe Anwendungen in klar abgegrenzte Komponenten zerlegt, die von einzelnen Teams verwaltet und unabhängig voneinander skaliert werden können, um das jeweilige Datenverkehrsaufkommen zu bewältigen.
Microservices bieten Entwicklern viele Vorteile, darunter mehr Flexibilität und Skalierbarkeit. Diese Vorteile gehen jedoch mit Kompromissen einher, etwa einer höheren Komplexität. Daher verfolgen viele Unternehmen einen API-First-Ansatz bei der Entwicklung von Microservices. Bei dieser Strategie beginnt der Entwurfsprozess für Anwendungen und Services mit einem API-Vertrag, der die Funktionsweise einer API bis hin zum Format von Anfragen und Antworten festlegt.
Mit der zunehmenden Verbreitung von APIs wächst die Angriffsfläche
Die Vorteile einer API-First-Softwareentwicklung können leicht zunichtegemacht werden, wenn die API-Sicherheit nicht ernst genommen wird – insbesondere bei der Konzeption und Bereitstellung. Grundsätzlich gilt: Je mehr APIs es gibt, desto größer ist die Angriffsfläche. APIs spielen zwar eine entscheidende Rolle in der modernen Softwareentwicklung, lassen sich zugleich jedoch immer leichter ausnutzen.
Im Jahr 2018 prognostizierte Gartner dass APIs bis 2022 zum häufigsten Angriffsvektor für Anwendungen werden würden. Wenn überhaupt, war die Annahme, dass dies noch so lange dauern würde, allzu optimistisch. Aufsehenerregende API-Sicherheitsverletzungen bei großen Unternehmen, von denen Millionen von Nutzern betroffen waren, ereigneten sich bereits damals und sind seitdem nur noch häufiger geworden:
- Im Jahr 2018 berichtete Facebook, dass die Daten von mindestens 50 Millionen Nutzern gefährdet waren, nachdem Angreifer die Entwickler-API des Unternehmens ausgenutzt hatten, um personenbezogene Daten (PII) aus den Profilseiten der Nutzer abzurufen, darunter Name, Geschlecht und Heimatort.
- 2019 berichtete LinkedIn, dass ein Hacker durch die Ausnutzung von APIs Daten-Scraping-Techniken einsetzte, um die Informationen von über 700 Millionen Nutzern zu sammeln, die anschließend im Darknet zum Verkauf angeboten wurden.
- Im Jahr 2021 ermöglichte eine von Peloton betriebene API es einem böswilligen Akteur, personenbezogene Daten wie Alter, Geschlecht, Wohnort, Gewicht und Geburtsdatum abzufragen.
- Im Jahr 2022 reagierte Twitter auf eine API-Sicherheitsverletzung, durch die Daten von 5,4 Millionen Benutzerkonten offengelegt wurden, darunter Telefonnummern und E-Mail-Adressen.
- Im Jahr 2023 meldete T-Mobile, dass eine Sicherheitsverletzung bei einer API zum Diebstahl der Daten von 37 Millionen Kunden geführt hatte, darunter Namen, E-Mail-Adressen, Anschriften, Telefonnummern, Geburtsdaten und weitere Angaben.
Das Ausmaß und die Vielfalt dieser Angriffe verdeutlichen die Herausforderungen, vor denen Verantwortliche für Sicherheit und Entwicklung stehen. Einige Angriffe nutzen APIs aus, die fälschlicherweise über das Internet zugänglich waren. Bei anderen kommen API-Schlüssel oder andere Authentifizierungsmethoden zum Einsatz, die versehentlich in Code-Repositorys offengelegt wurden. Oder Angreifer verschaffen sich durch das Ausnutzen von VPN-Schwachstellen Zugang zu internen Umgebungen und schleusen mithilfe interner APIs Daten aus.
Zur Abwehr von API-Angriffen braucht es die richtige Strategie und die richtigen Tools
Der gängigste Ansatz zum Schutz vor API-Bedrohungen besteht darin, traditionelle Sicherheitsstrategien für Webanwendungen mit modernen API-Sicherheitstechniken zu kombinieren. Angesichts der vielfältigen API-Bedrohungen von heute reichen traditionelle Strategien häufig nicht aus. Moderne Techniken wie die automatisierte API-Erkennung und API-Kontrasttests sollen diese Lücken schließen.
Für Unternehmen ist es von entscheidender Bedeutung, Shield Right zu betreiben (globale Kontrollen und Sicherheitsrichtlinien zum Schutz bereitgestellter Anwendungen und APIs zu implementieren) und Shift Left umzusetzen (Sicherheit in den Code zu integrieren, um Schwachstellen zu beseitigen, bevor Anwendungen und APIs in die Produktion gehen). Keine der beiden Strategien kann allein umfassende API-Sicherheit gewährleisten. Der Schlüssel zur Vermeidung von Sicherheitsverletzungen liegt daher in einem ganzheitlichen Ansatz, der drei Kategorien von API-Sicherheitspraktiken umfasst:
- Management der API-Sicherheitslage– Bietet Einblick in den Sicherheitsstatus einer Sammlung von APIs, einschließlich der Arten offengelegter Daten und der Anfragemethoden
- API-Sicherheitstests – Bewertet die Sicherheit einer API an wichtigen Punkten ihres Lebenszyklus, um potenzielle Schwachstellen zu identifizieren
- API-Laufzeitschutz– Erkennt und verhindert, dass bösartige Anfragen während des Betriebs APIs erreichen
Durch die Kombination der richtigen Strategie mit den richtigen Tools können Unternehmen ihre APIs besser vor Angriffen schützen und die Sicherheit ihrer Softwaresysteme gewährleisten. Sehen wir uns die wichtigen Funktionen und Tools an, die Führungskräfte im Bereich Platform Engineering implementieren müssen, um APIs während ihres gesamten Lebenszyklus zu schützen.
Was ist API Security Posture Management?
Das API Security Posture Management schafft Transparenz über die Anzahl, Arten und Standorte Ihrer APIs sowie über die von ihnen offengelegten Daten. Mithilfe dieser Informationen können Sie die mit jeder API verbundenen Risiken besser einschätzen und geeignete Maßnahmen zu ihrem Schutz ergreifen.
Wichtige Funktionen:
- Automatisierte API-Erkennung – Automatische und kontinuierliche API-Erkennung für einen umfassenden Überblick über die in einer Umgebung bereitgestellten APIs
- API-Charakterisierung – Identifizieren und kategorisieren Sie APIs nach Protokoll oder Architektur (REST, GraphQL, SOAP usw.) und bilden Sie sensible Datenflüsse ab, um Ihre Risikoexposition zu verstehen
- API-Katalogisierung – Führen Sie eine vollständige Liste aller APIs, damit Softwareteams vorhandene APIs wiederverwenden können und SecOps-Teams einen umfassenden Überblick über Ihre Sicherheitslage erhalten
Repräsentative Technologien:
- Web application and API protection (WAAP) – Nutzt eine privilegierte globale Position in der API-Infrastruktur, um den ein- und ausgehenden Datenverkehr von Umgebungen zu analysieren, APIs zu identifizieren und einen Überblick über Ihre Risikoexposition zu erstellen
- Inline- oder agentenbasierte Erkennung – Bindet einen Agenten an vorhandene API-Gateways, Load Balancer oder Kubernetes-Ingress-Controller an, um den API-Datenverkehr zu spiegeln und zu analysieren
- Out-of-Band- oder agentenlose Erkennung – Verwendet Traffic-Spiegelung oder exportierte Protokolle und Metriken zur Analyse des API-Datenverkehrs; bietet in der Regel weniger Einblick in APIs und Bedrohungen als andere Technologien
- Domain-Crawler – Anbieter von API-Sicherheitslösungen stellen möglicherweise Crawler bereit, die Ihre Domain auf offengelegte API-Endpunkte untersuchen, über die Datenverkehr Ihre API-Gateways und Load Balancer umgehen kann, an denen Sicherheitsrichtlinien durchgesetzt werden können
Dabei ist zu beachten, dass keine Technologie zuverlässig jede API in Ihrer Architektur finden kann. Die meisten Erkennungstechniken sind auf die von vorhandenen Load Balancern, API-Gateways und Ingress-Controllern bereitgestellte Sichtbarkeit angewiesen und können Fehlkonfigurationen, die diese Architekturkomponenten umgehen, wahrscheinlich nicht erkennen.
Letztlich bieten Code-Reviews und die Einhaltung bewährter API-First-Praktiken langfristig einen wirksameren Schutz. Automatisierte Tools zur API-Erkennung sind jedoch weiterhin nützlich, um sich schnell einen Überblick über Ihre Sicherheitslage zu verschaffen und APIs aufzuspüren, die andernfalls möglicherweise unverwaltet und ungeschützt blieben.
Was sind API-Sicherheitstests?
Während sich das Management der API-Sicherheitslage mit der unternehmensweiten Sicherheit befasst, konzentrieren sich API-Sicherheitstests auf einzelne APIs. Im Wesentlichen helfen API-Sicherheitstests dabei, Schwachstellen und die damit verbundenen Risiken zu erkennen und zu vermeiden, indem die API-Laufzeitumgebung – also die hinter der API ausgeführte Anwendung – getestet wird. So lässt sich sicherstellen, dass grundlegende Sicherheitsanforderungen erfüllt sind, darunter Vorgaben für Authentifizierung, Autorisierung, Ratenbegrenzung und Verschlüsselung.
Wichtige Funktionen:
- API-Vertragstests – Verwendet die OpenAPI-Spezifikation einer API, um durch den Vergleich von Clientanfragen und Serverantworten zu überprüfen, ob sie wie vorgesehen funktioniert. Dabei kommt ein „Inside-out“-Ansatz zum Einsatz, um Schwachstellen in APIs zu erkennen, bevor diese bereitgestellt werden.
- Dynamische Anwendungssicherheitstests (DAST) – Simuliert Angriffe auf eine API-Laufzeitumgebung, um Schwachstellen zu finden, und bewertet die API dabei wie ein böswilliger Benutzer von „außen nach innen“.
Repräsentative Technologien:
- Software für API-Vertragstests – Spezialisierte Tools zur Durchführung von Tests, die API-Anfragen und -Antworten getrennt untersuchen, um zu überprüfen, ob das Verhalten von Client und Server dem API-Vertrag entspricht
- Software für Anwendungssicherheitstests (AST) – Tools, die Anwendungen einschließlich APIs durch die Simulation von Angriffen analysieren und testen
Es gibt sowohl Open-Source-Tools für Vertragstests als auch kommerzielle Produkte von spezialisierten Anbietern für API-Sicherheit. Der Markt für Anwendungssicherheitstests (Application Security Testing, AST) besteht bereits seit Jahrzehnten, und immer mehr Anbieter stellen spezielle Tools zum Scannen und Testen von APIs bereit.
Was ist API-Laufzeitschutz?
API-Laufzeitschutz bezeichnet die Absicherung von APIs während ihres Betriebs und der Verarbeitung von Anfragen. Dabei steht die Integration von Sicherheitsmaßnahmen sowohl in die Plattforminfrastruktur als auch in den Code der APIs selbst im Vordergrund. Ziel ist es, schädliche API-Anfragen, die nach der Bereitstellung auftreten, zu erkennen und zu verhindern.
Wichtige Funktionen:
- Zugriffskontrolle – Richtlinien für Authentifizierung (authN) und Autorisierung (authZ) durchsetzen
- Network security – Kommunikation im gesamten Netzwerk verschlüsseln und schützen
- Anwendungsschutz – Schützt API-Laufzeitumgebungen vor bösartigen API-Anfragen und Angriffen
- Echtzeitüberwachung – Angriffe in der gesamten API-Infrastruktur visualisieren, nachverfolgen und abwehren
Repräsentative Technologien:
- API-Gateway – Wendet Sicherheitsrichtlinien an und setzt sie durch, einschließlich Authentifizierung, Autorisierung, Ratenbegrenzung, Zugriffskontrolllisten und Verschlüsselung
- Web Application Firewall (WAF) – Schützt APIs und Anwendungen vor komplexen Angriffen auf Schicht 7, indem der Datenverkehr aktiv überwacht und anhand von Angriffssignaturen gefiltert wird
- Identitätsanbieter (IdP) – Dienst, der Benutzeridentitäten speichert und überprüft und in der Regel mit Single-Sign-on-Anbietern (SSO) zusammenarbeitet, um Benutzer zu authentifizieren
Nicht alle API-Gateways und WAFs/WAAPs sind gleich. Einigen Diensten, insbesondere den nativen Lösungen auf Cloud- und anderen Plattformen, mangelt es an der globalen Transparenz und Standardisierung, die für Multi-Cloud- und Hybridarchitekturen erforderlich sind.
Best Practices für API-Sicherheit
Angesichts der Bedeutung sicherer APIs ist es unerlässlich, die API-Sicherheit strukturiert anzugehen. Verantwortliche für Platform Engineering und Sicherheit müssen zusammenarbeiten, um die Sicherheitsanforderungen über den gesamten API-Lebenszyklus hinweg zu erfüllen. Wie bereits erläutert, lässt sich dies grob in drei zentrale Praxisbereiche unterteilen: API Security Posture Management, API-Sicherheitstests und API-Laufzeitschutz. Mit anderen Worten: Sie müssen wissen, wie viele APIs Sie haben, wie Sie diese auf Fehler testen und wie Sie Sicherheit in Ihren Code integrieren.
Fazit
Wie alle Bereiche der Cybersicherheit ist auch die API-Sicherheit ein fortlaufender Prozess, der die Zusammenarbeit mit zahlreichen Beteiligten erfordert, darunter Netzwerkingenieure, Verantwortliche für den Sicherheitsbetrieb und das Platform Engineering sowie Softwareentwickler. Die gute Nachricht ist, dass die Absicherung von APIs kein großes Geheimnis ist.
Die meisten Unternehmen haben bereits Maßnahmen ergriffen, um bekannte Angriffe wie Cross-Site-Scripting, Injection, Distributed Denial of Service und andere Angriffe abzuwehren, die auf APIs abzielen können. Viele der oben beschriebenen Best Practices dürften erfahrenen Sicherheitsexperten zudem bereits bestens vertraut sein. Unabhängig davon, wie viele APIs Ihr Unternehmen betreibt, sollte Ihr Ziel darin bestehen, solide API-Sicherheitsrichtlinien zu etablieren und diese langfristig proaktiv zu verwalten.
Starten Sie Ihre kostenlose 30-Tage-Testversion des NGINX API Connectivity Stack, der den F5 NGINX Management Suite API Connectivity Manager zur Verwaltung, Steuerung und Absicherung von APIs, F5 NGINX Plus als API-Gateway sowie F5 NGINX App Protect WAF und DoS für erweiterte API-Sicherheit umfasst.
Weitere Ressourcen
- Blog: Schützen Sie Ihr API-Gateway mit NGINX App Protect WAF
- Blog: Schützen Sie Ihre bidirektionalen GraphQL- und gRPC-Streaming-APIs mit F5 NGINX App Protect WAF
- E-Book: Sicherheit für moderne Anwendungen und APIs
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.