API-Sicherheit im Unternehmen: In 5 Schritten zur robusten Schnittstellenstrategie

12 Min. Lesezeit

Ihre Entwickler haben gerade das neueste API-Update ausgerollt, der Product Owner feiert den Launch – und niemand hat geprüft, ob der neue Endpunkt Kundendaten ohne Authentifizierung ausliefert. Genau so passieren die teuersten Sicherheitsvorfälle im Mittelstand: nicht durch raffinierte Hacker, sondern durch vergessene Schnittstellen.

Das Wichtigste in Kürze

• 🚨 99 Prozent aller Unternehmen hatten im vergangenen Jahr mindestens einen API-Sicherheitsvorfall – APIs sind der Angriffsvektor Nummer eins
• 💰 API-bezogene Sicherheitsvorfälle verursachen weltweit geschätzte Kosten von 186 Milliarden US-Dollar jährlich
• 🔍 Die OWASP API Security Top 10 decken 128 Schwachstellentypen ab und bilden den Standard-Prüfrahmen
• ⚙️ Ein strukturiertes API-Sicherheitsprogramm lässt sich in fünf Schritten aufbauen – vom Inventar bis zum Monitoring
• 🎯 Unternehmen sollten mit einem Budget von 15.000 bis 45.000 Euro für die Erstabsicherung rechnen, je nach API-Landschaft

Warum API-Sicherheit 2026 Chefsache ist

APIs sind das Nervensystem jeder modernen IT-Architektur. Ob CRM, ERP, Cloud-Plattform oder mobile App: Ohne Programmierschnittstellen läuft nichts. Gleichzeitig wachsen APIs schneller als die Fähigkeit der meisten Unternehmen, sie zu schützen. Gartner prognostizierte bereits 2022, dass APIs zum wichtigsten Angriffsvektor werden. 2026 ist diese Prognose längst Realität.

Die Zahlen sind deutlich: Laut aktuellen Erhebungen hatten 99 Prozent aller Organisationen im vergangenen Jahr mindestens einen API-Sicherheitsvorfall. Über 90 Prozent aller webbasierten Angriffe zielen mittlerweile auf API-Endpunkte. Und die meisten Unternehmen können nicht einmal grundlegende Fragen beantworten: Wie viele API-Endpunkte existieren im eigenen Netzwerk? Welche Berechtigungen hat jeder einzelne Zugang?

Der Fall Samsung Deutschland: Wenn eine vergessene Schnittstelle 270.000 Datensätze freilegt

Wie real die Gefahr ist, zeigt ein Vorfall aus dem März 2025. Ein Angreifer mit dem Pseudonym „GHNA“ verschaffte sich Zugang zum Kunden-Ticketsystem von Samsung Deutschland. Die Methode war nicht besonders raffiniert: Er nutzte Zugangsdaten, die bereits 2021 durch die Schadsoftware Racoon Infostealer vom Rechner eines Mitarbeiters der Partnerfirma Spectos GmbH gestohlen worden waren.

Das Ergebnis: 270.000 Kundendatensätze mit Namen, E-Mail-Adressen, Bestellnummern, Tracking-URLs und Support-Kommunikation landeten öffentlich im Netz. Der Sicherheitsdienstleister Hudson Rock hatte Samsung bereits Jahre zuvor auf die kompromittierten Zugangsdaten hingewiesen. Sie wurden nie zurückgesetzt.

Dieser Fall verdeutlicht drei Kernprobleme, die in vielen Unternehmen existieren: fehlende Credential-Rotation bei Partnerintegrationen, kein Monitoring ungewöhnlicher API-Zugriffsmuster und mangelnde Sichtbarkeit über die eigene Schnittstellenlandschaft.

„Die OWASP API Security Top 10 bilden einen idealen Leitfaden für eine strukturierte API-Sicherheitsprüfung mit einem vernünftigen Verhältnis von Aufwand und Nutzen.“

GUTcert / Nimrod Briller, IT-Sicherheitsexperte, Februar 2026

Schritt 1: API-Inventar erstellen – Sie können nicht schützen, was Sie nicht kennen

Der erste und wichtigste Schritt klingt banal, scheitert aber in der Praxis am häufigsten. Weniger als die Hälfte aller Enterprise-APIs werden laut Gartner aktiv gemanagt. Der Rest sind sogenannte Shadow APIs: Schnittstellen, die Entwicklerteams für Tests angelegt, für Migrationen genutzt oder bei einem Relaunch vergessen haben.

Beginnen Sie mit einem automatisierten API-Discovery-Scan. Tools wie Salt Security, Traceable oder Noname Security erkennen aktive Endpunkte im Netzwerkverkehr. Ergänzen Sie das Ergebnis mit einer manuellen Abfrage bei allen Entwicklungsteams: Welche APIs existieren? Welche davon sind dokumentiert? Welche haben externe Zugänge?

Zeitrahmen: Rechnen Sie für ein mittelständisches Unternehmen mit 2 bis 4 Wochen für eine vollständige Bestandsaufnahme. Das Ergebnis sollte eine OpenAPI/Swagger-Dokumentation aller aktiven Endpunkte sein.

Schritt 2: Authentifizierung und Autorisierung härten

Broken Object Level Authorization (BOLA) steht auf Platz 1 der OWASP API Security Top 10 – und das seit Jahren. Der Grund: Viele APIs prüfen zwar, ob ein Nutzer angemeldet ist, aber nicht, ob dieser Nutzer auf das angeforderte Objekt zugreifen darf. Ein Angreifer ändert einfach die ID in der URL und erhält Zugriff auf fremde Datensätze.

Die Lösung besteht aus drei Ebenen:

• OAuth 2.0 mit OpenID Connect als Standard-Authentifizierung. JWT-Tokens mit RS256-Algorithmus und einer maximalen Gültigkeit von 15 Minuten.
• Objekt-Level-Autorisierung bei jedem einzelnen API-Aufruf. Jede Anfrage muss gegen die Berechtigung des anfragenden Nutzers geprüft werden – nicht nur beim Login.
• Zentrale Policy-Engine wie Open Policy Agent (OPA) oder Casbin, statt Berechtigungslogik über den Code zu verstreün.

Budget: Für die Implementierung einer zentralen Auth-Lösung mit einem Managed Service wie Auth0, Okta oder Keycloak rechnen Sie mit 5.000 bis 15.000 Euro Einrichtungskosten plus laufende Lizenzgebühren ab circa 2 Euro pro Nutzer und Monat.

Schritt 3: Rate Limiting und Input-Validierung implementieren

Ohne Ratenbegrenzung ist jede API ein offenes Tor für Brute-Force-Angriffe, Credential Stuffing und Datenexfiltration. Ein gestaffeltes Modell hat sich bewährt: Anonyme Zugriffe auf 100 Anfragen pro Stunde begrenzen, authentifizierte Standardnutzer auf 1.000, Premium-Integrationen auf 10.000.

Gleichzeitig muss jede API-Eingabe strikt validiert werden. Das bedeutet: Schema-Validierung für JSON-Payloads, parametrisierte Abfragen gegen SQL-Injection, Begrenzung der Payload-Größe und Komplexitätslimits für verschachtelte Abfragen. API-Gateways wie Kong, Apigee oder AWS API Gateway bieten diese Funktionen out of the box.

Zeitrahmen: Die Grundkonfiguration eines API-Gateways mit Rate Limiting dauert für ein erfahrenes Team 1 bis 2 Wochen. Die feinkörnige Abstimmung pro Endpunkt kann weitere 2 bis 4 Wochen in Anspruch nehmen.

Schritt 4: Security Testing in die CI/CD-Pipeline integrieren

API-Sicherheit darf kein einmaliges Audit sein. Jedes Code-Update, jeder neue Endpunkt und jede geänderte Berechtigung muss automatisiert getestet werden. Das gelingt durch Integration von Sicherheitstests direkt in die Deployment-Pipeline.

Bewerten Sie drei Testebenen:

• Statische Analyse (SAST): SonarQube, Semgrep oder CodeQL scannen den Quellcode auf bekannte Schwachstellen, bevor er deployed wird. Pre-Commit-Hooks fangen hartcodierte Secrets ab.
• Dynamische Analyse (DAST): OWASP ZAP oder Burp Suite testen laufende APIs automatisiert auf die OWASP Top 10. Integrieren Sie diese Scans als Stage in Ihre CI/CD-Pipeline.
• Manuelle Penetrationstests: Für kritische Endpunkte, die Zahlungsdaten, personenbezogene Daten oder Steuerungsfunktionen verarbeiten, bleibt ein manueller Pentest durch externe Experten unverzichtbar.

Budget: OWASP ZAP ist Open Source. Kommerzielle DAST-Lösungen kosten ab 5.000 Euro jährlich. Ein externer Pentest für 20 bis 50 API-Endpunkte liegt bei 8.000 bis 20.000 Euro.

Schritt 5: Monitoring, Incident Response und kontinuierliche Verbesserung

Die beste Absicherung nützt wenig, wenn niemand bemerkt, dass ein Angreifer seit Wochen über eine vergessene API Daten abzieht. Etablieren Sie ein API-spezifisches Monitoring, das mindestens folgende Signale erfasst:

• Alle fehlgeschlagenen Authentifizierungsversuche
• Ungewöhnliche Zugriffsmuster auf sequenzielle IDs (typisch für BOLA-Angriffe)
• Spitzen bei Rate-Limit-Überschreitungen
• Zugriffe auf als deprecated markierte Endpunkte
• Ungewöhnlich grosse Response-Payloads

Tools wie Datadog, der ELK-Stack oder Splunk lassen sich mit API-spezifischen Dashboards erweitern. Spezialisierte Plattformen wie Salt Security oder Traceable bieten zusätzlich Verhaltensanalysen und automatische Anomalie-Erkennung.

Wichtig: Definieren Sie einen API-spezifischen Incident-Response-Plan. Wer wird benachrichtigt, wenn ein Endpunkt ungewöhnliche Zugriffe zeigt? Wie schnell können einzelne API-Keys revoked werden? Samsung Deutschland hätte den Vorfall vermeiden können, wenn ein automatisches Alerting bei Nutzung von vier Jahre alten Credentials existiert hätte.

Die Gegenposition: Ist API Security nicht einfach gutes Software Engineering?

Einige Stimmen aus der Entwickler-Community argumentieren, dass API-Sicherheit kein eigenes Thema sein sollte. Wer sauberen Code schreibt, Input validiert und Authentifizierung korrekt implementiert, brauche keine dedizierte API-Security-Strategie.

Dieser Einwand hat einen wahren Kern. In der Praxis scheitert er jedoch an drei Faktoren: Erstens wachsen API-Landschaften schneller als die Kapazität einzelner Teams, sie zu überblicken. Zweitens führen Microservice-Architekturen dazu, dass Dutzende Teams unabhängig voneinander APIs entwickeln, ohne zentrale Sicherheitsstandards. Und drittens zeigen die OWASP-Daten, dass selbst erfahrene Teams systematisch bestimmte Schwachstellentypen übersehen, insbesondere bei Business-Logic-Fehlern und Autorisierungsprüfungen.

Die Antwort liegt in der Mitte: Gutes Engineering ist die Basis, aber ohne organisatorische Leitplanken, automatisierte Prüfungen und zentrale Governance reicht es nicht.

Was das BSI 2026 ändert: Grundschutz++ und maschinenlesbare Sicherheit

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) treibt mit dem Projekt „Grundschutz++“ eine umfassende Modernisierung voran. Ab 2026 wird der IT-Grundschutz auf ein maschinenlesbares JSON-Format umgestellt, das Schnittstellen für Security-Management-Tools bereitstellen soll. Für Unternehmen bedeutet das konkret: API-Sicherheitsanforderungen lassen sich künftig automatisiert gegen den Grundschutz-Katalog prüfen.

Parallel dazu verstärkt die NIS2-Richtlinie den Druck auf Unternehmen, ihre gesamte IT-Infrastruktur – einschliesslich API-Schnittstellen – systematisch abzusichern. Wer ohnehin ein Informationssicherheitsmanagementsystem (ISMS) betreibt oder aufbaut, sollte API-Security als eigenes Modul integrieren.

Checkliste: API-Sicherheit im Unternehmen in 90 Tagen

Woche 1 bis 4: Discovery und Bestandsaufnahme

• Automatisierten API-Discovery-Scan durchführen
• Alle aktiven Endpunkte in OpenAPI/Swagger dokumentieren
• Shadow APIs identifizieren und deaktivieren oder dokumentieren
• Credential-Inventar erstellen: Welche API-Keys und Service-Accounts existieren?

Woche 5 bis 8: Härtung und Testing

• OAuth 2.0 / OpenID Connect als Standard-Auth implementieren
• Rate Limiting pro Endpunkt konfigurieren
• DAST-Scanner in die CI/CD-Pipeline integrieren
• Ersten externen Pentest für kritische Endpunkte beauftragen

Woche 9 bis 12: Monitoring und Governance

• API-Monitoring-Dashboard einrichten
• Alerting-Regeln für Anomalien definieren
• API-Sicherheitsrichtlinie für alle Entwicklungsteams veröffentlichen
• Vierteljährlichen Review-Zyklus etablieren

Gesamtbudget-Rahmen: Für ein mittelständisches Unternehmen mit 50 bis 200 API-Endpunkten rechnen Sie mit 15.000 bis 45.000 Euro für das initiale Setup (Tools, Beratung, erster Pentest). Laufende Kosten für Monitoring und Lizenzgebühren liegen bei 2.000 bis 5.000 Euro monatlich.

Fazit: Starten Sie mit dem Inventar

API-Sicherheit ist kein Projekt, das irgendwann fertig ist. Es ist ein kontinuierlicher Prozess, der mit einer einzigen Frage beginnt: Welche Schnittstellen existieren in unserem Unternehmen, und wer hat Zugriff darauf? Wenn Sie diese Frage heute nicht beantworten können, ist das Ihr erster Handlungsschritt.

Starten Sie diese Woche mit dem API-Inventar. Kein Tool-Kauf, keine externe Beratung: Sammeln Sie in einer gemeinsamen Tabelle mit Ihren Entwicklungsteams alle bekannten API-Endpunkte, deren Authentifizierungsmethode und den letzten Review-Zeitpunkt. Allein diese Uebung wird Lücken aufdecken, die sofortiges Handeln erfordern.

Häufige Fragen

Was versteht man unter API-Sicherheit?

API-Sicherheit umfasst alle Maßnahmen, die Programmierschnittstellen vor unbefugtem Zugriff, Datenmissbrauch und Angriffen schützen. Dazu gehören Authentifizierung, Autorisierung, Verschlüsselung, Input-Validierung, Rate Limiting und kontinuierliches Monitoring. Der Referenzrahmen dafür sind die OWASP API Security Top 10, die die zehn kritischsten Schwachstellentypen bei APIs beschreiben.

Welche API-Schwachstelle ist am gefährlichsten?

Broken Object Level Authorization (BOLA) führt die OWASP API Security Top 10 seit Jahren an. Bei BOLA-Angriffen manipuliert ein Angreifer die Objekt-ID in einer API-Anfrage und erhält Zugriff auf Daten anderer Nutzer. Die Schwachstelle entsteht, wenn eine API zwar die Identität des Nutzers prüft, aber nicht dessen Berechtigung für das angefragte Objekt.

Was kostet es, API-Sicherheit im Mittelstand einzuführen?

Für ein mittelständisches Unternehmen mit 50 bis 200 API-Endpunkten liegen die initialen Kosten bei 15.000 bis 45.000 Euro. Das umfasst API-Discovery-Tools, die Implementierung einer zentralen Authentifizierungslösung, Integration von Sicherheitstests in die CI/CD-Pipeline und einen ersten externen Pentest. Laufende Kosten für Monitoring und Tool-Lizenzen betragen 2.000 bis 5.000 Euro monatlich.

Wie viele APIs hat ein typisches Unternehmen?

Die Anzahl variiert stark, aber selbst mittelständische Unternehmen betreiben oft 50 bis 300 API-Endpunkte. Weniger als die Hälfte davon sind laut Gartner aktiv gemanagt und dokumentiert. Shadow APIs, also nicht dokumentierte oder vergessene Schnittstellen, stellen dabei das größte Risiko dar, weil sie oft mit veralteten Berechtigungen und ohne Monitoring laufen.

Wie hängen API-Sicherheit und NIS2 zusammen?

Die NIS2-Richtlinie verpflichtet Unternehmen in kritischen Sektoren zu einem systematischen Risikomanagement für ihre IT-Infrastruktur. APIs fallen als zentrale Kommunikationsschnittstellen explizit in den Geltungsbereich. Unternehmen müssen nachweisen, dass sie Schnittstellen inventarisiert, abgesichert und überwacht haben. Verstösse können zu empfindlichen Bußgeldern führen.

Weiterführende Artikel im SecurityToday-Netzwerk

• Zero Trust für den Mittelstand: Einstieg in 5 Schritten (SecurityToday)
• Supply Chain Security 2026: So schützen Unternehmen ihre Software-Lieferkette (SecurityToday)
• NIS2 in Deutschland: Was Unternehmen jetzt wissen und umsetzen müssen (SecurityToday)
• Multi-Cloud-Sicherheit 2026: Die 5 größten Risiken und wie man sie löst (SecurityToday)
• AIOps: Wie KI den Cloud-Betrieb automatisiert und Ausfälle verhindert (cloudmagazin)
• Revenue Operations: Was hinter dem RevOps-Boom steckt (MyBusinessFuture)

Quelle Titelbild: Pexels / Tima Miroshnichenko

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor Alec Chizhik