Bedrohung Schatten-Schnittstellen : Shadow-APIs : Vom unsichtbaren Risiko zur proaktiven Kontrolle – eine strategische Roadmap zur Absicherung der digitalen Wertschöpfungskette

Eine solche Definition wird vor allem durch die Umsetzung von Threat-Modelling möglich (bspw. nach dem STRIDE-Framework [4]). Eine solche Modellierung durchleuchtet die Architektur und Konzeption von bereits bestehender oder neu geplanter Infrastruktur/Applikationen und betrachtet, welche Möglichkeiten Angreifer hätten, um in diese einzudringen. Jede Anfrage, die nicht strikt dem erwarteten Positive-Security-Model-Schema entspricht, wird verworfen. Um diesen Zustand zu erreichen, wird das Vorgehensmodell einer proaktiven Forensik wie folgt in fünf Phasen auf die API-Security adaptiert:

Phase 1: Initiale Bestandsaufnahme (Discovery & Inventory)

Man kann nicht schützen, was man nicht sieht – die Erstellung eines vollständigen Inventars ist daher ein kritischer Schritt für den Erfolg. Statische Listen sind in modernen API-Umgebungen allerdings zum Scheitern verurteilt: Klassische Ansätze, bei denen Entwickler ihre Schnittstellen manuell in Excel-Tabellen oder Configuration-Management-Databases (CMDBs) eintragen, können mit der Dynamik agiler CI/CD-Prozesse nicht Schritt halten – Endpunkte ändern sich dort oft täglich. Selbst automatisch generierte Dokumentationen wie Swaggeroder OpenAPI-Dateien sind häufig schon veraltet, sobald der Code produktiv ausgerollt wird.

Um einen realistischen Überblick über vorhandene APIs zu erhalten, ist daher ein automatisierter, datenverkehrsbasierter Ansatz erforderlich. Ein solches „Traffic-Based Discovery“ analysiert tatsächliche Log-Daten aus Gateways und Load-Balancern. Moderne Lösungen greifen dafür auf unüberwachtes maschinelles Lernen (Unsupervised Learning) zurück, um Muster im Datenverkehr zu erkennen und API-Endpunkte dynamisch zu erfassen.

Ein zentraler Bestandteil dieses Prozesses ist die Mustererkennung: Der eingesetzte Algorithmus muss variable Pfadsegmente eigenständig abstrahieren können – etwa indem er Endpunkte wie /api/user/123 und /api/ user/456 zu einem generischen Pfad /api/user/{id} zusammenfasst. Auf diese Weise lässt sich die API-Struktur konsistent und skalierbar abbilden.

Darüber hinaus deckt dieser Ansatz nicht nur bislang unbekannte Shadow-APIs auf, sondern auch sogenannte Zombie-APIs: alte, eigentlich längst abgelöste Endpunkte – etwa /v1/login –, die nach einem Versionswechsel auf /v2/ weiterhin aktiv bleiben. Da solche Endpunkte oft nicht mehr gewartet oder gepatcht werden, stellen sie ein erhebliches Sicherheitsrisiko dar.

Phase 2: Anforderungsdefinition (Schema)

Ist der Bestand bekannt, muss man für jeden Endpunkt definieren, wie legitime Kommunikation aussieht – ein weiterer zentraler Schritt ist daher die automatisierte Schema-Generierung. Auf Basis des tatsächlich beobachteten Datenverkehrs lassen sich automatisch OpenAPI-Spezifikationen ableiten (OAS v3, vgl. https://spec. openapis.org/oas/). Das System erkennt dazu selbstständig, wie sich eine API verhält – beispielsweise in einem Commerce-Szenario, in dem der Endpunkt /payment ausschließlich POST-Requests akzeptiert und der RequestBody ein JSON-Objekt mit den Feldern amount (Integer) und currency (String, maximal drei Zeichen) enthält. Auf diese Weise entsteht eine aktuelle und konsistente APIDokumentation direkt aus der Nutzung heraus.

Parallel dazu muss ein Risiko-Audit erfolgen, in dem alle identifizierten APIs zu klassifizieren sind. Im Zuge dessen ist ebenfalls zu prüfen, welche Schnittstellen personenbezogene Daten (PII) verarbeiten, welche öffentlich zugänglich und welche nur intern erreichbar sind – und welche Kritikalität die jeweiligen Daten aufweisen. Diese Kategorisierung bildet die Grundlage für eine gezielte Sicherheitsbewertung und Priorisierung.

Ein häufiges Ergebnis dieser Analyse ist die Entdeckung von Authentifizierungs-Lücken: Immer wieder zeigt sich, dass interne APIs versehentlich öffentlich erreichbar sind oder keine Authentifizierung verlangen. Das übergeordnete Ziel besteht daher in der Etablierung eines verbindlichen Standards: Keine API sollte ohne Authentifizierung (wie OAuth2 oder OpenID-Connect) in den Live-Betrieb gehen!

Phase 3: Implementierung von Schutzmaßnahmen (Enforcement)

Die Durchsetzung definierter Regeln sollte zentralisiert per Web-Application-and-API-Protection-(WAAP)- Plattform erfolgen – idealerweise in Form eines ReverseProxy am Netzwerkrand (Edge), um Angriffe fernzuhalten, bevor sie die Infrastruktur erreichen (API-Gateway).

In Phase drei übernimmt ein solches API-Gateway die Rolle eines strengen Türstehers: Es überprüft jede eingehende Anfrage anhand der zuvor definierten Schemata und stellt sicher, dass nur Anfragen verarbeitet werden, die den vorgegebenen Strukturen entsprechen. Enthält eine Anfrage zusätzliche oder unerwartete Parameter – ein typisches Anzeichen für Mass-Assignment-Angriffe – oder weist sie falsche Datentypen auf, wird sie unmittelbar blockiert. Auf diese Weise lässt sich verhindern, dass manipulierte Payloads bis zum Backend durchdringen.

Für die Kommunikation zwischen Maschinen, also im Kontext von Machine-to-Machine- oder Service-to-Service-Verbindungen, sollte zudem Mutual TLS (mTLS) eingesetzt werden, bei dem sich Client und Server gegenseitig über kryptografische Zertifikate authentifizieren. Dadurch lassen sich Man-in-the-Middle-Angriffe effektiv ausschließen und es wird sichergestellt, dass nur autorisierte Systeme – etwa IoT-Geräte, Partneranwendungen oder Backend-Services – miteinander kommunizieren.

Sicherheit muss jedoch auch in die entgegengesetzte Richtung gedacht werden: Eine Sensitive-Data-Detection sorgt dafür, dass Proxies ausgehende Antworten automatisch auf vertrauliche Informationen prüfen. So lässt sich verhindern, dass sensible Daten, wie Kreditkartennummern oder Sozialversicherungsinformationen, durch Fehlkonfigurationen oder Programmierfehler versehentlich im Klartext übermittelt werden. Diese zusätzliche Kontrollschicht schützt somit nicht nur vor Datenlecks, sondern hilft auch, regulatorische Vorgaben einzuhalten.

Phase 4: Simulation und Abwehr von Logik-Angriffen

Die gefährlichsten Angriffe auf APIs zielen heute auf die Geschäftslogik (Business-Logic-Abuse). Klassische WAF-Regeln greifen dabei nicht, da die verwendeten Anfragen syntaktisch korrekt sind. Ein zentraler Bestandteil moderner API-Security ist daher der Schutz vor sogenannter Broken-Object-Level-Authorization (BOLA) – laut den „OWASP Top 10 API Security“ [5] das derzeit höchste Risiko.

Bei einem BOLA-Angriff authentifiziert sich der Angreifer zwar korrekt als Benutzer A, manipuliert jedoch die Objekt-ID in der URL, um auf Daten von Benutzer B zuzugreifen. Schutzmechanismen müssen hier sicherstellen, dass die angeforderte ID tatsächlich zum authentifizierten Token gehört. Ergänzend sollten Systeme in der Lage sein, verdächtige Abweichungen im Zugriffsverhalten automatisch zu erkennen, um unberechtigte Datenzugriffe frühzeitig zu blockieren.

Darüber hinaus gilt es, zwischen volumetrischen und sequenziellen Angriffen zu unterscheiden: Während klassische DDoS-Schutzmaßnahmen massenhafte Anfragen abwehren, verlaufen API-Angriffe häufig nach dem „Low-and-Slow“-Prinzip. Sequential Modeling bietet hier einen wirksamen Ansatz: Das System lernt die typischen Aufrufmuster einer Anwendung – etwa „1. Login → 2. Suche → 3. Warenkorb → 4. Kauf“. Versucht ein Client, diese Reihenfolge zu umgehen und beispielsweise direkt den Kauf-Endpunkt in großer Anzahl aufzurufen, um limitiertes Inventar zu blockieren (sog. Scalping), wird dieses abweichende Verhalten als Anomalie erkannt und automatisiert verhindert.

Ein weiteres wichtiges Element ist Adaptive RateLimiting: Statt fixer Anfragelimits pro IP-Adresse erfolgen die Beschränkungen hierbei dynamisch pro Session-ID oder API-Token. Auf diese Weise lässt sich der Effekt verteilter Bot-Netzwerke deutlich reduzieren, während man legitime Nutzer nicht unnötig einschränkt.

Phase 5: Kontinuierliche Verbesserung und „Future-Proofing“

Heutige IT-Landschaften sind volatil – neue Technologie schafft neue Vektoren, auf die eine Sicherheitsarchitektur vorbereitet sein muss. 2026 werden mehr als 80% der Unternehmen generative KI einsetzen [3] – ein Trend, der neben enormem Potenzial auch neue Sicherheitsrisiken mit sich bringt. Besonders heikel ist dabei das sogenannte „Model-Scraping“: Dabei versuchen Angreifer, über ein API große Mengen an Antworten oder Trainingsdaten abzugreifen, um eigene Modelle zu trainieren oder internes Wissen zu rekonstruieren. Klassische Rate Limiting-Mechanismen stoßen hier an ihre Grenzen – sie müssen so weiterentwickelt werden, dass sie nicht nur auf Anfragevolumen reagieren, sondern auch ungewöhnliche API-Nutzungsmuster erkennen, die auf automatisiertes Abschöpfen von KI-Wissen hindeuten.

Ein weiteres, noch immer häufig unterschätztes Risiko betrifft die Post-Quantum-Kryptografie (PQC): Für besonders langlebige Daten – etwa Gesundheitsinformationen, Forschungsdaten oder staatliche Geheimnisse – reicht eine klassische Verschlüsselung langfristig längst nicht mehr aus. Denn Angreifer verfolgen bereits heute die Strategie „Harvest Now – Decrypt Later“: Sie speichern verschlüsselten Datenverkehr, um ihn in einigen Jahren mithilfe leistungsfähiger Quantencomputer zu entschlüsseln.

Um diesem Szenario vorzubeugen, sollten IT-Architekten an ihren API-Gateways schon jetzt hybride Schlüsseleinigungsverfahren einführen – beispielsweise durch die Kombination von X25519 mit dem Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). Diese Verfahren lassen sich rein softwarebasiert auf dem TLS-Layer implementieren und erfordern keine neue Hardware. Sie schützen damit heutigen Datenverkehr effektiv vor künftigen Entschlüsselungsrisiken in einer Post-Quanten-Ära.

Technical Best Practices

Während die hier beschriebene Strategie den architektonischen Rahmen bildet, entscheidet sich die eigentliche Sicherheit oft an der Konsole: Admins, Engineers und DevOps-Teams können durch gezielte Härtungsmaßnahmen (Hardening) auf Infrastrukturebene die Resilienz gegen Shadow-API-Risiken massiv erhöhen. Folgende fünf technische Maßnahmen haben sich in der Praxis als effektivste Quick Wins erwiesen:

Maßnahme 1: Header-Hygiene und Fingerprint-Vermeidung

Angreifer beginnen oft mit der Aufklärung (Reconnaissance) – Standardkonfigurationen von Webservern und Frameworks verraten dabei unnötig viele Details über die verwendete Technik (z.B. „X-Powered-By: Express oder Server: nginx/1.18.0“). Um keine unnötigen Hinweise auf eingesetzte Software oder Versionen zu geben, sollte man alle versionsspezifischen Server-Banner entfernen und API-Gateways so konfigurieren, dass sie standardmäßig nur generische Fehlerseiten und Header ausliefern.

Darüber hinaus ist es wichtig, Sicherheit konsequent auf Protokollebene durchzusetzen: Header-StrictTransport-Security (HSTS) verhindert DowngradeAttacken, bei denen Verbindungen von HTTPS auf unsicheres HTTP umgeleitet werden könnten. Und mit „X-Content-Type-Options: nosniff“ stellt man sicher, dass Browser und Clients ausschließlich den deklarierten Content-Type akzeptieren, wodurch das Risiko von MIMESniffing-Angriffen minimiert wird – etwa wenn eine Bilddatei fälschlicherweise als ausführbares Skript interpretiert würde.

Auch wenn viele APIs kein direktes Frontend besitzen, kann eine strikte Content-Security-Policy (CSP) zusätzlichen Schutz bieten. Ein restriktiver Header wie default-src ‚none‘; frame-ancestors ‚none‘ verhindert, dass API-Antworten missbräuchlich in andere Webseiten eingebettet oder durch fremde Skripte manipuliert werden.

Maßnahme 2: Strikte Typisierung und Payload-Begrenzung

Ein häufiger Vektor für Denial-of-Service (DoS) auf Applikationsebene sind übergroße Payloads, die Parser zum Absturz bringen oder den Speicher (über-)füllen (Buffer-Overflow).

Für Ingress-Controller oder Reverse-Proxies sollte man daher strikte Grenzen für die maximale Größe des Request-Bodys definieren – beispielsweise 1 MB für Standard-JSON-Aufrufe. Anfragen, die dieses Limit überschreiten, sind bereits auf dieser Ebene mit dem http-Statuscode 413 „Payload Too Large“ abzuweisen, bevor sie die Applikationslogik erreichen. So lassen sich Ressourcen schonen und potenzielle Angriffsversuche durch übergroße Payloads frühzeitig stoppen.

Ebenso wichtig ist die Härtung der JSON-Parser in den Backend-Services: Diese sollten so konfiguriert sein, dass sie Anfragen mit unbekannten Feldern im JSON-Objekt nicht stillschweigend akzeptieren, sondern mit einem Fehler abbrechen. Dadurch werden Mass-Assignment-Attacken erschwert, bei denen Angreifer versuchen, interne Felder wie „is_admin: true“ gezielt zu manipulieren oder zu erraten.

Maßnahme 3: Implementierung von Traceability (Correlation IDs)

Bei einem Angriff über Shadow-APIs ist die Forensik oft schwierig, da Logs über verschiedene Punkte in der Infrastruktur verstreut sind. Aus diesem Grund sollte am API-Gateway für jede Anfrage eine eindeutige Request-ID erzeugt werden, etwa in Form einer (pseudo-) zufälligen UUID (Version 4 gem. RFC 4122). Diese Kennung wird anschließend als HTTP-Header – beispielsweise X-Request-ID oder als „Traceparent“ nach Trace-Context-Standard des W3C (www.w3.org/TR/trace-context/) – an alle nachgelagerten Services weitergegeben.

Jeder Log-Eintrag – unabhängig davon, ob er von Gateway, Backend oder Datenbank stammt – muss diese ID enthalten. Nur so lässt sich bei einem Sicherheitsvorfall der vollständige Pfad einer Anfrage nachvollziehen und rekonstruieren, selbst wenn sich ein Angreifer lateral durch verschiedene Systeme bewegt hat.

Maßnahme 4: JSON-Web-Token-(JWT)-Best-Practices

Viele moderne APIs nutzen JSON-Web-Token (JWTs) zur Authentifizierung – viele Unternehmen machen hier jedoch Fehler in der Implementierung. Es gilt dabei, schwache Signaturalgorithmen konsequent zu verbieten: Validierungs-Bibliotheken müssen so konfiguriert sein, dass der Algorithmus none strikt abgelehnt wird. Zudem sollten vorzugsweise asymmetrische Verfahren wie RS256 oder ES256 genutzt werden, da sie das Risiko von Schlüsselkompromittierungen gegenüber symmetrischen Verfahren wie HS256 deutlich reduzieren.

Außerdem dürfen Access-Tokens nur kurzzeitig gültig sein – in der Regel zwischen fünf und fünfzehn Minuten, für längere Sitzungen können zusätzliche RefreshTokens eingesetzt werden. Dadurch reduziert man das Zeitfenster auf ein Minimum, in dem sich ein gestohlenes Token missbrauchen lässt.

Darüber hinaus sollte der Audience-Claim (aud) im Token aktiv genutzt werden, um sicherzustellen, dass ein Token nur für den beabsichtigten Dienst gültig ist. Dann kann etwa ein Token, das für den Rechnungsservice ausgestellt wurde, nicht zur missbräuchlichen Authentifizierung beim Admin-Service dienen.

Maßnahme 5: Netzwerk-Segmentierung und Egress-Filter

Ein kompromittierter API-Endpunkt wird oft als Sprungbrett für Lateral Movements genutzt, um interne Datenbanken oder Metadaten-Services (wie den CloudInstanz-Metadaten-Service) abzufragen.

APIs, die sich im internen Netzwerk oder in einem Intranet befinden, dürfen daher standardmäßig keine Verbindungen ins öffentliche Internet aufbauen. Der ausgehende Datenverkehr ist auf Firewall-Ebene strikt auf notwendige Partner-APIs zu beschränken – eine konsequente Allow-Listing-Strategie verhindert unkontrollierte oder unerwünschte Kommunikation nach außen. So lässt sich eine Datenexfiltration durch kompromittierte Komponenten effektiv unterbinden.

In Kubernetes-Umgebungen ist zudem der interne Traffic zwischen Pods durch Mutual TLS (mTLS) im Rahmen eines Service-Mesh zu verschlüsseln und gegenseitig zu authentifizieren. Ergänzend können gezielte Network-Policies dafür sorgen, dass nur logisch verbundene Services miteinander kommunizieren – etwa das Frontend mit dem Backend, nicht jedoch direkt mit der Datenbank.

Fazit

Durch die Anwendung des beschriebenen FünfPhasen-Modells sowie eines Positive-Security-Models wandelt sich die API-Sicherheit von einem reaktiven „Brandlöschen“ zu einem integrierten Governance-Prozess.

Das Ergebnis ist eine drastische Reduktion der Angriffsfläche: Shadow-APIs werden eliminiert oder in offizielle und überwachte Kanäle überführt. Sicherheitsvorfälle lassen sich durch Schema-Validierung präventiv verhindern, anstatt nur nachträglich analysieren. Zudem ermöglicht dieser Ansatz eine Konsolidierung der Tools: Anstatt auf separate Lösungen für DDoS, WAF, Bot-Management und API-Gateway zu setzen, ermöglicht eine moderne Edge-Architektur die Bündelung dieser Funktionen – das reduziert Latenzen, Komplexität und Kosten.

Im Zeitalter von „Cloud-Native“ und künstlicher Intelligenz (KI) sind APIs nicht mehr nur technisches Beiwerk, sondern das wichtigste Asset der digitalen Infrastruktur. Wer seine APIs nicht kennt und kontrolliert, handelt fahrlässig!

Die hier vorgestellte Strategie einer proaktiven API-Governance bietet einen klaren Fahrplan: Der Prozess beginnt mit einer automatisierten Discovery, gefolgt von der Durchsetzung eines strikten Schemas bis hin zu verhaltensbasierten Analysen zur Überprüfung der Logik. Auf diese Weise lassen sich Compliance-Anforderungen zuverlässig erfüllen und durch ein hohes Maß an Security das Vertrauen der Kunden in einer zunehmend vernetzten Welt erhalten.

Max Imbiel ist Field CISO DACH, David Tofan ist Solutions Engineer bei Cloudflare

Literatur

_{[1] Michael Tremante, Sabina Zejnilovic, Catherine Newcomb, Application Security report: 2024 update, Cloudflare-Blog, Juli 2024, https://blog.cloudflare.com/application-security-report-2024-update/}

_{[2] John Cosgrove, Sabina Zejnilovic, Neuer Cloudflare-Bericht zu API-Sicherheit und -Verwaltung 2024, Cloudflare-Blog, Januar 2024, https://blog.cloudflare.com/de-de/2024-api-security-report/}  

_{[3] Cloudflare, 2024 API Security & Management Report, Januar 2024, https://cf-assets.www.cloudflare.com/slt3lc6tev37/34fZmoyhTkkjr06Z1zB8jb/7689bc9330302e0b3fc5baec353afa61/BDES5122_API-Security-Report.pdf – deutsche Fassung abrufbar via www.cloudflare.com/de-de/2024-api-security-management-report/ (Registrierung erforderlich)}

_{[4] Open Worldwide Application Security Project (OWASP) Community, Threat Modeling Process – STRIDE, undatiert, https://owasp.org/www-community/Threat_Modeling_Process#stride}

_{[5] Open Worldwide Application Security Project (OWASP), OWASP API Security Top 10 – Edition 2023, August 2023, https://owasp.org/API-Security/editions/2023/en/0x00-header/}