APIs: Die neue Angriffsfläche

APIs (Programmierschnittstellen) sind zur am häufigsten angegriffenen Ebene moderner Software geworden: Laut dem Akamai-Bericht „State of the Internet 2024“ zielten 150 Milliarden der insgesamt 311 Milliarden Webangriffe im Jahr 2024 auf APIs ab. APIs ermöglichen den direkten programmatischen Zugriff auf Anwendungslogik und sensible Daten und verbreiten sich schneller als die entsprechenden Sicherheitsmaßnahmen. Die empfohlene Vorgehensweise: Behandeln Sie jede API als privilegierten Zugriffspunkt, erzwingen Sie TLS 1.3 und Mutual TLS für den gesamten Datenverkehr, implementieren Sie eine objektbasierte Autorisierung an jedem Endpunkt und überwachen Sie das API-Verhalten kontinuierlich auf Anomalien, die durch Signaturen allein nicht erkannt werden können.

Kurzantwort: Warum sind APIs die neue Angriffsfläche?

APIs haben traditionelle Anwendungsschichten aus drei sich gegenseitig verstärkenden Gründen als primäre Angriffsfläche abgelöst. Erstens ermöglichen sie den direkten, programmatischen Zugriff auf sensible Daten und Geschäftslogik ohne die Einschränkungen einer Benutzeroberfläche. Zweitens vervielfachen sie sich rasant, da Unternehmen Microservices entwickeln und Drittanbieterplattformen integrieren. Dadurch entstehen Hunderte von Endpunkten pro Anwendung mit inkonsistenten Sicherheitskontrollen. Drittens unterscheiden sich API-spezifische Schwachstellen wie Broken Object Level Authorization (BOLA, OWASP API1:2023) strukturell von herkömmlichen Web-Schwachstellen und werden von Standard-WAF-Regeln oder für HTML-Seiten entwickelten Schwachstellenscannern nicht erkannt. Laut einem Bericht von FireTail aus dem Jahr 2024 waren 57 % der Unternehmen in den letzten zwei Jahren mindestens einmal von einem API-Sicherheitsvorfall betroffen, und 73 % der betroffenen Unternehmen erlebten drei oder mehr Vorfälle.

Was ist API-Sicherheit?

Eine API ist ein Regelwerk, das die Kommunikation zwischen Softwareanwendungen ermöglicht. Sie definiert, wie Anfragen gestellt, Daten ausgetauscht und Antworten strukturiert werden, und erlaubt so die standardisierte Zusammenarbeit von Systemen. APIs bilden die Grundlage nahezu aller modernen Technologie-Stacks: Banking-Apps, Gesundheitsportale, E-Commerce-Plattformen, Cloud-Infrastrukturen und interne Microservices kommunizieren alle über API-Aufrufe.

REST-APIs (Representational State Transfer) sind weiterhin der dominierende Standard. GraphQL-APIs (Graph Query Language) ermöglichen es Clients, die benötigten Daten präzise zu spezifizieren und haben neue Angriffsflächen geschaffen, darunter Introspektionsmissbrauch und die Erschöpfung tief verschachtelter Abfragen. gRPC (Google Remote Procedure Call) nutzt Protocol Buffers und HTTP/2 für die hochperformante Kommunikation mit Diensten. WebSocket-APIs ermöglichen die persistente bidirektionale Kommunikation für Echtzeitanwendungen. Jeder API-Typ verfügt über ein spezifisches Sicherheitsprofil, das über die allgemeine Sicherheit von Webanwendungen hinausgehende, besondere Kontrollmaßnahmen erfordert.

API-Sicherheit bezeichnet die Kontrollmechanismen, die APIs vor unberechtigtem Zugriff, Datenverlust, Missbrauch und Dienstverweigerung schützen. Da APIs direkte Einfallstore in Anwendungs-Backends darstellen, ist eine schwache API-Sicherheit häufig der Weg des geringsten Widerstands für Angreifer, die die herkömmlichen Perimeterkontrollen bereits ausgeschöpft haben.

API-Bedrohungsmodell: Angriffsvektoren und ihre Ausnutzung

OWASP API Security Top 10 (2023)	Was es ausnutzt	Beispiel	Primäre Kontrolle
API1: Autorisierung auf Ebene defekter Objekte (BOLA)	Fehlende Autorisierungsprüfungen pro Objekt; die API überprüft die Authentifizierung, aber nicht, ob der Benutzer die jeweilige Ressource besitzt.	Die Änderung von /api/orders/1234 zu /api/orders/1235 liefert die Bestellung eines anderen Benutzers.	Erzwingen Sie die Autorisierung auf Objektebene an jedem Endpunkt, nicht nur auf Sitzungsebene.
API2: Fehlerhafte Authentifizierung	Schwache Tokenvalidierung, fehlendes Ablaufdatum, Akzeptanz von Token von falschen Ausstellern	JWT ohne Algorithmus akzeptiert; abgelaufene Token werden nicht abgelehnt	JWT-Signatur und -Ansprüche validieren; Token-Ablauf erzwingen; kurzlebige Token verwenden
API3: Autorisierung auf Ebene fehlerhafter Objekte	Die API gibt mehr Felder zurück oder akzeptiert mehr Felder, als der Benutzer sehen oder festlegen darf.	Massenzuweisungsangriff mit der Einstellung admin:true in einer Benutzeraktualisierungsanfrage	Explizite Zulassungsliste lesbarer und beschreibbarer Felder pro Endpunkt und Rolle
API4: Uneingeschränkter Ressourcenverbrauch	Keine Ratenbegrenzung; die API verarbeitet unbegrenzt viele Anfragen, wodurch CPU-, Speicher- oder nachgelagerte Kosten entstehen.	Massenaufzählung von Benutzerdatensätzen; Abfrageerschöpfung durch tief verschachtelte GraphQL-Abfragen	Ratenbegrenzung pro API-Schlüssel, IP-Adresse und Benutzer; Begrenzungen der Abfragetiefe und -komplexität für GraphQL
API5: Fehlerhafte Autorisierung auf Funktionsebene	Administrative API-Funktionen, die Nicht-Administratoren zugänglich sind	Nicht-Administrator greift auf /api/admin/users zu, um alle Benutzer aufzulisten	Separate Admin-APIs; rollenbasierte Zugriffskontrolle auf Funktionsebene erzwingen
API6: Uneingeschränkter Zugriff auf sensible Geschäftsprozesse	APIs, die risikoreiche Geschäftslogik (Kontoerstellung, Zahlung) ohne Ablaufsteuerung ermöglichen.	Automatisierung der Kontoerstellung zum Aufbau einer Bot-Armee zur Bestandsverwaltung für den Einzelhandelskasern	Ratenbegrenzung für Geschäftslogik; CAPTCHA für sensible Datenflüsse; Anomalieerkennung von Datenflussmustern
API7: Serverseitige Anforderungsfälschung (SSRF)	Die API ruft vom Benutzer bereitgestellte URLs ab und ermöglicht so den Zugriff auf interne Dienste.	Die API ruft eine URL ab, die auf den internen Metadatendienst verweist und dabei Cloud-Zugangsdaten offenlegt.	Zulässige URL-Ziele auf die Zulassungsliste setzen; private IP-Bereiche auf Anwendungsebene blockieren.
API8: Sicherheitsfehlkonfiguration	Standardanmeldeinformationen, ausführliche Fehlermeldungen, offene Debug-Endpunkte, fehlendes TLS	Elasticsearch-Datenbank ohne Authentifizierung zugänglich; API gibt Stacktraces bei Fehlern zurück.	Debug-Modi in der Produktion deaktivieren; generische Fehlermeldungen verwenden; Konfigurationen prüfen.
API9: Unsachgemäße Bestandsverwaltung	Nicht dokumentierte oder veraltete API-Endpunkte sind weiterhin aktiv und werden nicht überwacht.	Legacy-v1-API-Endpunkt mit schwächerer Authentifizierung, aktiv neben gehärteter v2-Authentifizierung.	Pflegen Sie ein vollständiges API-Inventar; entfernen Sie veraltete Versionen; überwachen Sie alle aktiven Endpunkte.
API10: Unsichere Nutzung von APIs	Die eigenen Systeme der Organisation vertrauen blindlings Daten von Drittanbieter-APIs ohne Validierung.	Die API des Zahlungsanbieters gibt eine schädliche Weiterleitungs-URL zurück, die ohne Validierung ausgeführt wird.	Behandeln Sie alle API-Antworten von Drittanbietern als nicht vertrauenswürdige Eingaben; validieren und bereinigen Sie sie vor der Verwendung.

API-Sicherheitsvorfälle in der Praxis: Was geschah wirklich?

• GitHub-Repositories (März 2024): Etwa 13 Millionen API-Geheimnisse wurden aufgrund mangelhafter Geheimnisverwaltung über öffentliche Repositories offengelegt. Angreifer nutzten diese Zugangsdaten, um sich unbefugten Zugriff auf Cloud-Dienste und nachgelagerte Anwendungen zu verschaffen. Prävention: Verwenden Sie in Ihren CI/CD-Pipelines Tools zum Scannen von Geheimnissen wie GitHub Advanced Security oder TruffleHog; speichern Sie API-Schlüssel, Tokens oder Zugangsdaten niemals in Code-Repositories.
• Dell-API-Sicherheitslücke (2024): Eine ungeschützte API im Partnerportal von Dell ermöglichte Angreifern den Zugriff auf Daten von 49 Millionen Kunden. Die Sicherheitslücke war auf unzureichende Drosselung von Anfragen und fehlende Anomalieerkennung im API-Verkehr zurückzuführen. Dies ist ein Paradebeispiel für OWASP API4 (unbeschränkter Ressourcenverbrauch) in Kombination mit API8 (Sicherheitsfehlkonfiguration).
• Missbrauch der Microsoft Graph API (Mai 2024): Angreifer nutzten die Microsoft Graph API, um verdeckte Malware-Kommunikationskanäle zu erstellen, die Tausende von Organisationen betrafen. Durch den rechtmäßig erlangten API-Zugriff umgingen sie herkömmliche Sicherheitsvorkehrungen. Es handelt sich hierbei um einen „Living off the Land“-Angriff (LotL): Schadsoftware nutzt legitime Tools, um sich in den normalen Geschäftsbetrieb einzufügen und erfordert daher Verhaltenserkennung anstelle signaturbasierter Kontrollen.
• APIsec-Vorfall (März 2025): Eine fehlerhaft konfigurierte Elasticsearch-Datenbank des API-Testunternehmens APIsec legte über drei Terabyte sensibler Kundendaten offen, darunter API-Scan-Ergebnisse, Konfigurationsgeheimnisse und personenbezogene Daten. Ein OWASP-API-8-Sicherheitsfehler auf Datenbankebene führte zur Offenlegung von Daten, die von einem API-Sicherheitstool erfasst worden waren.
• Tee-App (2025): Eine anonyme Social-Media-App wurde Opfer eines Sicherheitsvorfalls, bei dem 1.1 Millionen private Nachrichten und Tausende von Ausweisdokumenten offengelegt wurden. Grund dafür waren unzureichend gesicherte Speicher- und API-Schnittstellen. Sensible Daten wie Telefonnummern und Ausweisdokumente waren über ungeschützte API-Schnittstellen zugänglich – ein kombinierter Fehler in API 8 und API 1.

Verschlüsselung und Protokollauswahl für API-Sicherheit

Die Verschlüsselung schützt API-Daten während der Übertragung und im Ruhezustand. Die Protokollauswahl bestimmt, ob die Verschlüsselung für die zu schützenden Daten ausreichend stark ist:

Kontrolle	Software Empfehlungen	Was man vermeiden sollte	Relevanz der Einhaltung
Verschlüsselung des externen API-Datenverkehrs	TLS 1.3; TLS_AES_256_GCM_SHA384 oder TLS_CHACHA20_POLY1305_SHA256	TLS 1.0, TLS 1.1, SSL; CBC-Modus-Verschlüsselungssammlungen; RSA-Schlüsselaustausch (ohne PFS)	Art. 32 DSGVO; HIPAA-Sicherheitsregel; PCI DSS Anforderung 4
Interne API-Authentifizierung zwischen Diensten	Mutual TLS (mTLS) mit zertifikatbasierter Identität pro Dienst	Gemeinsam genutzte statische API-Schlüssel ohne Rotation; keine Authentifizierung zwischen internen Diensten	PCI DSS Anforderung 8; Anforderungen an die Zero-Trust-Architektur
API-Geheimnisse und Anmeldeinformationen im Ruhezustand	AES-256-GCM in einem dedizierten Geheimnisverwaltungssystem oder HSM; niemals in Code-Repositories	Klartext in Umgebungsvariablen, Konfigurationsdateien oder Quellcodeverwaltung	HIPAA; PCI DSS Anforderung 3; DSGVO Art. 32
Tokenübertragung	Autorisierungsheader (Bearer-Token); niemals in URL-Abfragezeichenfolgen.	Tokens in URL-Abfrageparametern (protokolliert von Proxys, CDNs und Serverzugriffsprotokollen)	PCI DSS Anforderung 6; OWASP API Security Top 10
Langlebige API-Daten (PQC-Überlegung)	Hybrid-TLS: ECDHE + ML-KEM (FIPS 203) für APIs, die Daten transportieren, die seit über 10 Jahren sensibel sind.	RSA-Schlüsselaustausch für APIs, die sensible Datensätze mit langer Aufbewahrungsdauer übertragen.	NIST IR 8547 2030 Abschaffungszeitplan

Authentifizierung, Autorisierung und Zugriffskontrollen

Fehler bei der Authentifizierung und Autorisierung machen den Großteil der ausnutzbaren API-Schwachstellen in den OWASP Top 10 2023 aus. Diese Kontrollmechanismen müssen auf jeder Ebene korrekt implementiert werden:

• OAuth 2.0 und OpenID Connect: OAuth 2.0 ist der Standard für delegierte Autorisierung; OpenID Connect (OIDC) ergänzt diese um eine Identitätsprüfung. Verwenden Sie für die benutzerorientierte API-Authentifizierung den Autorisierungscode-Flow mit PKCE (Proof Key for Code Exchange). Maschine-zu-Maschine-APIs sollten den Client-Credentials-Flow mit kurzlebigen Zugriffstoken nutzen.
• JWT-Validierung (JSON Web Token): Prüfen Sie bei jeder Anfrage die Signatur, den Aussteller (iss-Claim), die Empfänger (aud-Claim) und das Ablaufdatum (exp-Claim). Akzeptieren Sie niemals JWTs mit dem Algorithmus „none“. Verwenden Sie für Multi-Service-Bereitstellungen asymmetrische Schlüsselverifizierung (RS256 oder ES256) anstelle von gemeinsam genutzten symmetrischen Geheimnissen (HS256).
• Multi-Faktor-Authentifizierung (MFA): Der vom Menschen initiierte API-Zugriff (Entwicklerportale, API-Verwaltungskonsolen) muss Folgendes erfordern: MFA. FIDO2-Passkeys oder zertifikatbasierte Authentifizierung Mit CertSecure Manager können Sie phishingresistente Alternativen zu TOTP bereitstellen.
• Gegenseitiges TLS (mTLS): mTLS mTLS erfordert, dass sowohl Client als auch Server während des TLS-Handshakes gültige Zertifikate vorlegen. Für interne Service-zu-Service-APIs in Microservice- oder Zero-Trust-Architekturen stellt mTLS sicher, dass nur autorisierte Dienste Verbindungen herstellen können. Dadurch wird die reine Anmeldeinformationsauthentifizierung, auf der BOLA und Angriffe mit fehlerhafter Authentifizierung basieren, eliminiert.
• OCSP-Heftung: ermöglichen OCSP-Heften auf API-Servern, um Zertifikatsgültigkeitsprüfungen in Echtzeit durchzuführen, ohne dass Clients die Zertifizierungsstelle separat abfragen müssen. Dies reduziert die Latenz und verhindert den Missbrauch widerrufener Zertifikate.
• Prinzip der minimalen Berechtigungen und rollenbasierte Zugriffskontrolle (RBAC): Jeder API-Client, Benutzer und jedes Dienstkonto erhält nur die für seine Funktion erforderlichen Mindestberechtigungen. Die rollenbasierte Zugriffskontrolle (RBAC) bzw. die attributbasierte Zugriffskontrolle (ABAC), die auf API-Gateway- und Objektebene durchgesetzt wird, behebt Fehler bei der Autorisierung auf BOLA- und Funktionsebene.

Überwachung, Protokollierung und Reaktion auf Vorfälle

API-Angriffe sind häufig nicht deshalb erfolgreich, weil es an Schutzmaßnahmen mangelt, sondern weil anomales Verhalten erst dann erkannt wird, wenn bereits erheblicher Schaden entstanden ist. Der Dell-Datendiebstahl beispielsweise war auf fehlende Anomalieerkennung im API-Datenverkehr zurückzuführen. Effektives Monitoring erfordert daher:

• Verhaltensbasislinie und Anomalieerkennung: Ermitteln Sie, wie der normale API-Traffic pro Endpunkt aussieht: erwartete Anfragevolumina, typische Client-IDs, übliche geografische Verteilung, normale Antwortgrößen. Abweichungen, wie beispielsweise 50,000 Anfragen pro Stunde durch einen einzelnen API-Schlüssel oder Antworten, die regelmäßig größer als der Basiswert sind, dienen als Erkennungssignale. Signaturbasierte Regeln erkennen bekannte Muster; Verhaltenserkennung deckt neuartige Angriffe und LotL-Missbrauch auf.
• SIEM-Integration: integriert SIEM Plattformen mit API-Gateway-Protokollen, Authentifizierungsprotokollen und Anwendungsprotokollen. Die SIEM-Korrelation identifiziert Angriffsmuster, die in einzelnen Protokollströmen normal erscheinen, aber anomal sind, wenn sie über verschiedene Quellen korreliert werden.
• Vollständige Audit-Protokollierung: Jede API-Anfrage wird mit Client-Identität, Endpunkt, HTTP-Methode, Anfrageparametern, Antwortcode, Antwortgröße und Zeitstempel protokolliert. Die Protokolle müssen in einer schreibgeschützten Umgebung getrennt von der Anwendung gespeichert werden, damit ein kompromittierter Server den Prüfpfad nicht verändern kann. Die Aufbewahrungsfristen der Protokolle müssen den geltenden regulatorischen Anforderungen entsprechen (12 Monate gemäß PCI DSS-Anforderung 10).
• API-Inventarüberwachung: Nicht dokumentierte und veraltete Endpunkte werden aufgrund mangelnder Überwachung immer wieder ausgenutzt. Pflegen Sie ein vollständiges API-Inventar und stellen Sie sicher, dass die Überwachung alle aktiven Endpunkte abdeckt, einschließlich veralteter Versionen, die nicht mehr unterstützt werden sollten.

Bewährte Verfahren zur Sicherung von APIs: Implementierungs-Checkliste

1. TLS 1.3 auf allen API-Endpunkten erzwingen; Deaktivieren Sie TLS 1.0, 1.1 und Cipher Suites ohne Perfect Forward Secrecy.
2. Implementieren Sie die Autorisierung auf Objektebene auf jedem Endpunkt; Gehen Sie nicht davon aus, dass die Authentifizierung auf Sitzungsebene ausreicht, um BOLA zu verhindern.
3. Alle Eingaben prüfen und bereinigen; JSON-Schema-Validierung für REST-APIs erzwingen, Abfragetiefen- und Komplexitätsgrenzen für GraphQL festlegen und fehlerhafte Anfragen ablehnen, bevor sie die Anwendungslogik erreichen.
4. Ratenbegrenzung pro API-Schlüssel, Benutzer und IP-Adresse implementieren; Bei wiederholten fehlgeschlagenen Authentifizierungsversuchen exponentielles Backoff anwenden.
5. Alle Geheimnisse sollten in einem dedizierten Geheimnisverwaltungssystem oder HSM gespeichert werden; API-Schlüssel nach einem festgelegten Zeitplan rotieren; Repositories nach versehentlich gespeicherten Anmeldeinformationen durchsuchen.
6. Verwenden Sie mTLS für die interne Kommunikation zwischen Diensten; Servicezertifikate werden über eine automatisierte Lebenszyklusmanagement-Plattform verwaltet.
7. Pflegen Sie ein vollständiges und aktuelles API-Inventar; Veraltete Endpunkte außer Betrieb nehmen; alle aktiven Endpunkte, einschließlich undokumentierter, überwachen.
8. Integrieren Sie DAST-Tools (Dynamic Application Security Testing) wie OWASP ZAP in CI/CD-Pipelines; Führen Sie vor jeder Bereitstellung API-spezifische Sicherheitstests durch.
9. Protokolliere jede API-Anfrage mit vollständigen Anfragemetadaten; Integration mit SIEM; Konfiguration von Anomalieerkennungsalarmen für Volumenspitzen, ungewöhnliche Zugriffsmuster und Antworten, die erheblich von der Basisgröße abweichen.
10. Führen Sie für jede neue API eine Bedrohungsmodellierung mit STRIDE durch; Ordnen Sie jede Bedrohungskategorie einer spezifischen Kontrollmaßnahme zu, und zwar vor dem Einsatz und nicht erst nach einem Sicherheitsvorfall.

Wie Verschlüsselungsberatung helfen kann

• Verschlüsselungsberatungsdienste: UNSERE Verschlüsselungsberatung Wir bewerten die API-Verschlüsselungsabdeckung, einschließlich TLS-Konfiguration, Auswahl der Cipher Suite, Geheimnisverwaltung und mTLS-Implementierung. Wir identifizieren Lücken zwischen dem aktuellen API-Sicherheitsstatus und den Anforderungen von NIST, DSGVO, HIPAA und PCI DSS und stellen einen priorisierten Fahrplan zur Behebung dieser Lücken bereit.
• Verschlüsselungsprüfungsdienst: UNSERE Verschlüsselungs-Audit-Dienst Wir bieten eine umfassende Prüfung der kryptografischen Verfahren Ihrer API-Infrastruktur und identifizieren dabei ungeschützte Geheimnisse, schwache Algorithmen, fehlende TLS-Verschlüsselung und Lücken in der PQC-Bereitschaft. Darüber hinaus bewerten wir die HNDL-Gefährdung von APIs, die langlebige, sensible Daten übertragen.
• CertSecure Manager: CertSecure Manager automatisiert das Zertifikatslebenszyklusmanagement für die in der internen API-Authentifizierung verwendeten mTLS-Zertifikate und deckt dabei Erkennung, Ausstellung, Erneuerung und Widerruf innerhalb Ihres Service Mesh ab.
• HSM als Dienstleistung: HSM als Service Die Hardware-Speicherung (HSM) ist gemäß FIPS 140-3 validiert und speichert die API-Signatur- und Verschlüsselungsschlüssel, deren Kompromittierung den gesamten API-Datenverkehr offenlegen würde. Die HSM-Speicherung verhindert die Schlüsselextraktion selbst bei einem Serverkompromittierungsfall.
• PQC Beratungsleistungen: UNSERE PQC-Beratungsdienste Beurteilen Sie, welche APIs durch die Quantenbedrohung einem HNDL-Risiko ausgesetzt sind, planen Sie hybride TLS-Implementierungen, die ECDHE mit ML-KEM (FIPS 203) kombinieren, und erstellen Sie einen neunphasigen Migrationsfahrplan, der auf den Abschaffungszeitplan 2030 von NIST IR 8547 abgestimmt ist.

Einschränkungen: Was API-Sicherheitskontrollen allein nicht leisten können

• Verschlüsselung verhindert keine Autorisierungsfehler: TLS sichert den Kanal, verhindert aber nicht BOLA. Ein Angreifer, der mit einem gültigen Token über eine ordnungsgemäß verschlüsselte Verbindung auf die Daten eines anderen Benutzers zugreift, ist dennoch erfolgreich. Verschlüsselung und Autorisierung sind separate Kontrollebenen, die unterschiedliche Bedrohungen abwehren.
• WAFs erkennen keine API-spezifischen Schwachstellen: Traditionelle Web Application Firewalls sind für Angriffe auf HTML-Seiten (XSS, SQL-Injection in Formularfeldern) ausgelegt und decken keine Schwachstellen der OWASP API Security Top 10 ab, wie z. B. BOLA oder Autorisierungsfehler auf Funktionsebene, deren Erkennung eine Logik auf Anwendungsebene erfordert.
• Statische Tests ersetzen die Laufzeitüberwachung nicht: DAST und Penetrationstests decken Schwachstellen vor der Bereitstellung auf; Verhaltensanomalieerkennung erkennt Angriffe im Produktivbetrieb. Beide Methoden ersetzen nicht die jeweils andere. LotL-Angriffe, bei denen legitimer Zugriff missbraucht wird, lassen sich nur durch Laufzeitverhaltensanalyse erkennen.
• API-Gateways sind keine vollständigen Sicherheitslösungen: Gateways bieten zentrale Authentifizierung, Ratenbegrenzung und Protokollierung, aber sie erzwingen keine Autorisierung auf Objektebene (die in der Anwendungslogik implementiert werden muss) und erkennen keinen LotL-Missbrauch (der eine Verhaltensüberwachung erfordert).

Fazit

APIs bilden das Rückgrat moderner digitaler Ökosysteme, und genau diese zentrale Rolle macht sie zum lukrativsten Ziel für Angreifer. Angesichts von 150 Milliarden API-Angriffen im Jahr 2024 und der Tatsache, dass 57 % der Unternehmen in den letzten zwei Jahren von API-Sicherheitsvorfällen betroffen waren, stellt sich nicht die Frage, ob die APIs eines Unternehmens ins Visier genommen werden, sondern ob die Sicherheitsvorkehrungen den Schaden im Ernstfall begrenzen können.

Effektive API-Sicherheit erfordert mehrschichtige Kontrollmechanismen, die unterschiedliche Bedrohungskategorien adressieren: TLS 1.3 mit mTLS für die Kanalsicherheit, OAuth 2.0 mit objektbasierter Autorisierung für die Zugriffskontrolle, Ratenbegrenzung und Anomalieerkennung zur Missbrauchsprävention, HSM-gestützte Geheimnisverwaltung zum Schutz von Anmeldeinformationen und kontinuierliche Verhaltensüberwachung für Angriffe, die von Signaturen nicht erkannt werden. Jede Schicht deckt eine spezifische Bedrohungsklasse ab; das Entfernen einer Schicht hinterlässt eine Lücke, die von den anderen nicht geschlossen werden kann.

Wenn Sie Ihre aktuelle API-Verschlüsselungssituation bewerten, Authentifizierungs- und Autorisierungslücken identifizieren oder kryptografische Kontrollen aufbauen möchten, die API-Daten schützen, wenn alles andere fehlschlägt, wenden Sie sich an Encryption Consulting, um eine API-Sicherheitsbewertung zu besprechen.

Häufig gestellte Fragen

Warum stellen APIs mittlerweile die dominierende Angriffsfläche dar?

APIs ermöglichen den direkten programmatischen Zugriff auf Anwendungslogik und sensible Daten, verbreiten sich schneller als Sicherheitsmaßnahmen und weisen Schwachstellen auf (z. B. BOLA, fehlerhafte Autorisierung auf Funktionsebene), die von gängigen Web-Sicherheitstools nicht erkannt werden. Von den 311 Milliarden Webangriffen im Jahr 2024 zielten 150 Milliarden auf APIs ab (Akamai 2024 SOTI). Firetail stellte fest, dass API-Sicherheitsvorfälle im Jahr 2024 im Vergleich zum Vorjahr um 80 % zunahmen.

Was ist BOLA (Broken Object Level Authorization)?

BOLA (OWASP API1:2023) tritt auf, wenn eine API einen Benutzer authentifiziert, aber nicht überprüfen kann, ob dieser zum Zugriff auf ein bestimmtes Objekt berechtigt ist. Ein Angreifer ändert die Objekt-ID in der Anfrage-URL, um auf die Daten eines anderen Benutzers zuzugreifen. Zur Prävention sind Autorisierungsprüfungen auf Objektebene an jedem Endpunkt erforderlich, nicht nur auf Sitzungsebene.

Welche Verschlüsselung ist für die API-Sicherheit erforderlich?

TLS 1.3 für den gesamten externen API-Datenverkehr; Mutual TLS (mTLS) für die interne Kommunikation zwischen Diensten; AES-256-GCM für API-Geheimnisse und sensible ruhende Daten, die in einem HSM oder einem Geheimnisverwaltungssystem gespeichert sind; Token in Authorization-Headern, niemals in URL-Parametern.

Was ist ein LotL (Living off the Land) API-Angriff?

Ein LotL-Angriff nutzt legitimen, autorisierten API-Zugriff für böswillige Zwecke. Der Angreifer nutzt keine Sicherheitslücke aus, um Zugriff zu erlangen; er missbraucht die vorgesehene Funktionalität einer API mithilfe von Zugangsdaten, die er sich rechtmäßig beschafft hat. Verhaltensbasierte Überwachung ist der primäre Erkennungsmechanismus, da signaturbasierte Tools nicht zwischen legitimer und böswilliger Nutzung desselben API-Aufrufs unterscheiden können.

Welche Compliance-Rahmenwerke erfordern API-Sicherheitskontrollen?

Artikel 32 der DSGVO fordert technische Maßnahmen zum Schutz personenbezogener Daten. Die HIPAA-Sicherheitsregel schreibt Zugriffskontrollen, Protokollierung und sichere Übertragung von elektronischen Gesundheitsdaten (ePHI) vor. Die PCI-DSS-v4.0-Anforderungen 4, 6, 7, 8 und 10 gelten für APIs, die Karteninhaberdaten verarbeiten. Die OWASP API Security Top 10 (2023) ist die wichtigste technische Referenz für API-spezifische Schwachstellenkategorien.

Wie wirken sich Post-Quanten-Anforderungen auf die API-Sicherheit aus?

APIs, die langlebige, sensible Daten übertragen, sind dem Quantenrisiko von HNDL (Harvest Now, Decrypt Later) ausgesetzt. Das NIST finalisierte ML-KEM (FIPS 203) und ML-DSA (FIPS 204) im August 2024. Organisationen sollten hybride TLS-Implementierungen (ECDHE + ML-KEM) für hochsensible APIs planen, um der im NIST IR 8547 vorgesehenen Abschaffung von RSA und ECC im Jahr 2030 Rechnung zu tragen.