Best Practices für die API-Sicherheit: Authentifizierung, Autorisierung und Ratenbegrenzung

APIs sind das Bindegewebe moderner Geschäftsplattformen. Ihr ERP kommuniziert über APIs mit Ihrem E-Commerce-Shop. Ihr Zahlungsgateway verarbeitet Transaktionen über APIs. Ihre mobile App ruft Daten über APIs ab. Und Angreifer wissen das: Gartner prognostiziert, dass APIs bis 2026 der häufigste Angriffsvektor für Unternehmens-Webanwendungen sein werden und traditionelle Webschnittstellen übertreffen werden.

Die OWASP API Security Top 10 zeigt, dass es sich bei den häufigsten API-Schwachstellen nicht um exotische Zero-Day-Schwachstellen handelt, sondern um grundlegende Authentifizierungsfehler, fehlerhafte Autorisierung und übermäßige Offenlegung von Daten. Hierbei handelt es sich um vermeidbare Mängel, die auf eine unzureichende Sicherheitsarchitektur und nicht auf ausgefeilte Angriffe zurückzuführen sind.

Wichtige Erkenntnisse

• OAuth2 mit PKCE ist der aktuelle Standard für die API-Authentifizierung; API-Schlüssel allein reichen für Produktionssysteme nicht aus
• Broken Object-Level Authorization (BOLA) ist die API-Schwachstelle Nummer eins – jeder Endpunkt muss den Ressourcenbesitz überprüfen
• Ratenbegrenzung ist eine Sicherheitskontrolle, nicht nur eine Leistungsoptimierung – sie verhindert Credential Stuffing, Enumeration und DoS – Die Eingabevalidierung an der API-Grenze verhindert Injektions-, Überlauf- und Geschäftslogikangriffe, bevor sie Ihre Datenbank erreichen

---

Authentifizierung: Identität nachweisen

Die Authentifizierung beantwortet die Frage „Wer stellt diese Anfrage?“ Bei APIs muss die Antwort kryptografisch überprüfbar, resistent gegen Replay-Angriffe und über verteilte Systeme hinweg skalierbar sein.

Vergleich der Authentifizierungsmethoden

Best Practices für OAuth2 und OIDC

OAuth2 mit OpenID Connect (OIDC) ist der Standard für die API-Authentifizierung in modernen Anwendungen. Wichtige Implementierungspraktiken:

Verwenden Sie den Autorisierungscode-Flow mit PKCE für alle Clienttypen, einschließlich Single-Page-Anwendungen und mobile Apps. Der implizite Fluss ist aufgrund der Offenlegung von Token im Browserverlauf und in Referrer-Headern veraltet.

Kurzlebige Zugriffstoken. Zugriffstoken sollten in 15–60 Minuten ablaufen. Verwenden Sie Aktualisierungstoken (sicher gespeichert, bei Verwendung rotiert), um neue Zugriffstoken ohne erneute Authentifizierung zu erhalten.

Token-Speicher. Speichern Sie Token niemals in localStorage oder sessionStorage (anfällig für XSS). Verwenden Sie HttpOnly-Cookies mit den Attributen Secure und SameSite. Behalten Sie SPAs, die Token direkt verwenden müssen, nur im Speicher und akzeptieren Sie den Kompromiss, dass bei der Seitenaktualisierung Sitzungsverluste entstehen.

Tokens gründlich validieren. Jede API-Anfrage muss die Signatur, den Ablauf, den Aussteller, die Zielgruppe und den Umfang des Tokens überprüfen. Entschlüsseln Sie das JWT nicht einfach und vertrauen Sie seinem Inhalt.

Token-Bindung. Binden Sie Token nach Möglichkeit mithilfe von DPoP-Headern (Demonstrating Proof-of-Possession) an den Client, der sie angefordert hat, um Token-Diebstahl und -Wiedergabe zu verhindern.

Überlegungen zur JWT-Sicherheit

JWTs sind das am häufigsten verwendete Tokenformat für APIs, bergen jedoch besondere Risiken:

• Verwenden Sie niemals den none-Algorithmus. Validieren Sie den alg-Header immer anhand einer Whitelist der erwarteten Algorithmen.
• Asymmetrische Algorithmen (RS256, ES256) gegenüber symmetrischen (HS256) für öffentlich zugängliche APIs bevorzugen. Asymmetrische Schlüssel ermöglichen die Token-Verifizierung ohne Weitergabe des Signaturschlüssels.
• Standardansprüche einschließen: iss (Aussteller), aud (Zielgruppe), exp (Ablaufdatum), iat (ausgestellt bei), sub (Betreff), jti (eindeutige ID für den Widerruf).
• Nutzlast klein halten. JWTs sind keine Datenbank. Schließen Sie nur die Ansprüche ein, die für Autorisierungsentscheidungen erforderlich sind. Rufen Sie bei Bedarf zusätzliche Daten von Benutzerinformationsendpunkten ab.
• Implementieren Sie den Token-Widerruf. Verwenden Sie kurze Ablaufzeiten in Kombination mit einer Token-Sperrliste (in Redis oder ähnlichem) für den sofortigen Widerruf, wenn Konten kompromittiert werden.

---

Autorisierung: Durchsetzung der Zugriffskontrolle

Durch die Authentifizierung erfahren Sie, wer die Anfrage stellt. Durch die Autorisierung erfahren Sie, was sie tun dürfen. Die OWASP API Top 10 listet Broken Object-Level Authorization (BOLA) als API-Schwachstelle Nummer eins auf, da sie sowohl die häufigste als auch die einflussreichste ist.

RBAC gegen ABAC

Role-Based Access Control (RBAC) weist Rollen Berechtigungen zu und Benutzer werden Rollen zugewiesen. Es ist einfach umzusetzen und zu überdenken.

Attributbasierte Zugriffskontrolle (ABAC) wertet Richtlinien anhand von Attributen des Benutzers, der Ressource, der Aktion und der Umgebung aus. Es unterstützt komplexere Regeln, ist jedoch schwieriger zu prüfen.

Für die meisten Geschäftsplattformen, einschließlich ERP- und E-Commerce-Systeme, ist RBAC in Kombination mit Überprüfungen des Ressourcenbesitzes ausreichend. Ziehen Sie ABAC in Betracht, wenn Ihre Autorisierungsregeln von Kontextfaktoren wie Zeit, Ort, Datenklassifizierung oder dynamischen Organisationshierarchien abhängen.

BOLA verhindern

Eine fehlerhafte Autorisierung auf Objektebene liegt vor, wenn eine API Benutzern den Zugriff auf oder die Änderung von Ressourcen anderer Benutzer durch Manipulation von Ressourcenkennungen ermöglicht. Wenn Sie beispielsweise /api/orders/12345 in /api/orders/12346 ändern, sollte die Bestellung eines anderen Benutzers nicht angezeigt werden.

Präventionsregeln:

1. Jeder Endpunkt muss den Ressourcenbesitz überprüfen. Verlassen Sie sich niemals ausschließlich auf die Authentifizierung. Nachdem Sie die Identität des Benutzers überprüft haben, stellen Sie sicher, dass er Zugriff auf die spezifische angeforderte Ressource hat.
2. Verwenden Sie indirekte Referenzen. Anstatt sequenzielle Datenbank-IDs offenzulegen, verwenden Sie UUIDs oder benutzerbezogene Referenznummern.
3. Auf der Datenebene erzwingen. Fügen Sie Eigentumsfilter (z. B. WHERE organization_id = ?) zu jeder Datenbankabfrage hinzu, nicht nur auf Controller-Ebene. Dies ist das Multi-Tenancy-Muster, das in der gesamten ECOSIRE-Plattformarchitektur verwendet wird.
4. Automatisierte Tests. Integrieren Sie Autorisierungsumgehungstests in Ihre CI/CD-Pipeline. Testen Sie für jeden Endpunkt, dass Benutzer A nicht auf die Ressourcen von Benutzer B zugreifen kann.

---

Ratenbegrenzung und -drosselung

Bei der Ratenbegrenzung handelt es sich um eine Sicherheitskontrolle, die Missbrauch verhindert, und nicht nur um eine Leistungsoptimierung, die eine Überlastung verhindert. Ohne Ratenbegrenzung können Angreifer Credential Stuffing mit Tausenden von Versuchen pro Sekunde durchführen, gültige Konten aufzählen, Ihren gesamten Produktkatalog durchsuchen oder Ihre API-Kontingente bei Upstream-Anbietern erschöpfen.

Ratenbegrenzungsstrategien

Ratenbegrenzung nach Endpunkttyp

Unterschiedliche Endpunkte sind unterschiedlichen Bedrohungsprofilen ausgesetzt und erfordern unterschiedliche Grenzwerte:

• Authentifizierungsendpunkte (Anmeldung, Token-Austausch): 5–10 Anfragen pro Minute und IP. Niedrige Grenzwerte verhindern Credential Stuffing und Brute Force.
• Passwort-Zurücksetzung/Kontowiederherstellung: 3–5 Anfragen pro Stunde und Konto. Verhindert die Aufzählung und den Missbrauch von Konten.
• Datenleseendpunkte: 100–1000 Anfragen pro Minute und Benutzer. Verhindert Kratzer bei normaler Nutzung.
• Datenschreibendpunkte: 30–60 Anfragen pro Minute und Benutzer. Verhindert automatisierten Missbrauch und Spam.
• Öffentliche Suchendpunkte: 20–60 Anfragen pro Minute und IP. Verhindert konkurrierendes Scraping.
• Webhook-Empfänger: Signaturen validieren statt Ratenbegrenzung, aber Anfragen verwerfen, die das erwartete Volumen überschreiten.

Ratenbegrenzungen implementieren

Geben Sie die richtigen HTTP-Statuscodes und Header zurück, damit Clients sich selbst regulieren können:

• 429 Zu viele Anfragen, wenn das Limit überschritten wird – Retry-After-Header mit der Anzahl der Sekunden, bis das Limit zurückgesetzt wird
• Header X-RateLimit-Limit mit der Gesamtzahl der zulässigen Anfragen – Header X-RateLimit-Remaining mit den im Fenster verbliebenen Anfragen
• Header X-RateLimit-Reset mit dem UTC-Zeitstempel beim Zurücksetzen des Fensters

Verwenden Sie einen zentralisierten Ratenbegrenzungsdienst (Redis-gestützt) anstelle von instanzbezogenen Beschränkungen, um zu verhindern, dass Angreifer Anfragen über Instanzen verteilen, um Beschränkungen zu umgehen.

---

Eingabevalidierung

Die Eingabevalidierung an der API-Grenze ist Ihre erste Verteidigungslinie gegen Injektionsangriffe, Pufferüberläufe und die Ausnutzung der Geschäftslogik. Alle Daten, die in Ihre API eingegeben werden, müssen hinsichtlich Typ, Format, Länge, Bereich und Geschäftsregeln validiert werden.

Die Top 10 der OWASP-API-Sicherheit

Die OWASP API Security Top 10 (Ausgabe 2023) identifiziert die kritischen Risiken, denen jede API begegnen muss:

Best Practices für die Validierung

Schemavalidierung. Definieren Sie Anforderungsschemata (mithilfe von JSON Schema, Zod oder OpenAPI-Spezifikation) und lehnen Sie alle Anforderungen ab, die nicht den Anforderungen entsprechen. Dadurch werden fehlerhafte Daten erfasst, bevor sie die Geschäftslogik erreichen.

Parametrisierte Abfragen. Verketten Sie Benutzereingaben niemals in SQL-, NoSQL- oder LDAP-Abfragen. Verwenden Sie parametrisierte Abfragen oder ORM-Methoden, die das Escapen automatisch verarbeiten. Dies ist eine kritische Sicherheitsregel für alle Geschäftsplattformen.

Durchsetzung des Inhaltstyps. Akzeptieren Sie nur erwartete Content-Type-Header. Eine API, die JSON erwartet, sollte XML, Formulardaten und andere Inhaltstypen ablehnen, um Parser-basierte Angriffe zu verhindern.

Antwortfilterung. Geben Sie niemals vollständige Datenbankeinträge an den Client zurück. Verwenden Sie DTOs (Data Transfer Objects), um explizit zu definieren, welche Felder in jeder Antwort enthalten sind. Interne Felder wie Passwort-Hashes, interne IDs und Audit-Metadaten sollten niemals in API-Antworten erscheinen.

Fehlerbehandlung. Gibt generische Fehlermeldungen an Clients zurück. Legen Sie niemals Stack-Traces, Datenbankfehler oder interne Systemdetails offen. Protokollieren Sie detaillierte Fehler serverseitig zum Debuggen.

---

API-Sicherheitsarchitekturmuster

API-Gateway-Muster

Ein API-Gateway sitzt allen Backend-Diensten vor und zentralisiert übergreifende Sicherheitsbedenken:

• Authentifizierung --- Validiert Token, bevor Anfragen die Backend-Dienste erreichen
• Ratenbegrenzung --- Erzwingt Beschränkungen auf Gateway-Ebene
• Anfrage-/Antworttransformation --- Entfernt vertrauliche Header und fügt Sicherheitsheader hinzu
• Protokollierung und Überwachung --- Erfasst den gesamten API-Verkehr zur Sicherheitsanalyse
• WAF-Integration --- Blockiert bekannte Angriffsmuster (SQL-Injection, XSS-Payloads)

Zu den beliebten API-Gateways gehören Kong, AWS API Gateway, Azure API Management und Traefik.

Dienst-zu-Dienst-Authentifizierung

Auch interne APIs zwischen Microservices erfordern eine Authentifizierung. Zu den Optionen gehören:

• Gegenseitiges TLS (mTLS) --- Sowohl Client als auch Server präsentieren Zertifikate. Stark, aber operativ komplex.
• Diensttoken --- Dienste authentifizieren sich mit vorab freigegebenen Token. Einfach, erfordert aber eine sichere Verteilung.
• Service Mesh --- Istio oder Linkerd verarbeiten mTLS automatisch zwischen Diensten in Kubernetes.
• OAuth2-Client-Anmeldeinformationen --- Dienste authentifizieren sich mithilfe der Client-ID und des Geheimnisses, um Zugriffstokens zu erhalten.

Für die Zero-Trust-Architektur ist die Service-to-Service-Authentifizierung unerlässlich, um laterale Bewegungen nach einem Verstoß zu verhindern.

---

Überwachung und Erkennung von Vorfällen

Die API-Sicherheitsüberwachung muss sowohl technische Signale (fehlgeschlagene Authentifizierungsversuche, ungewöhnliche Anforderungsmuster) als auch geschäftliche Signale (anomale Transaktionsbeträge, Massendatenzugriff) erfassen.

Kritische API-Sicherheitssignale

• Authentifizierungsfehler --- Anstieg fehlgeschlagener Anmeldungen von einer einzelnen IP oder einem einzelnen Konto
• Autorisierungsfehler --- 403-Antworten weisen darauf hin, dass Benutzer versuchen, auf nicht autorisierte Ressourcen zuzugreifen
• Verletzungen des Ratenlimits --- 429 anhaltende Antworten aus derselben Quelle
• Ungewöhnliche Datenmengen --- Massenlesevorgänge, die auf eine Datenexfiltration schließen lassen
• Parametermanipulation --- Sequentielle ID-Aufzählung, negative Werte, Grenztests
• Geografische Anomalien --- API-Aufrufe aus unerwarteten Regionen oder unmöglichen Reisemustern

Erstellen Sie Dashboards, die diese Signale in Echtzeit anzeigen. Integrieren Sie es in Ihr SIEM, um eine Korrelation mit anderen Sicherheitsereignissen zu ermöglichen. Definieren Sie automatisierte Reaktionen für hochverdächtige Bedrohungen: Blockieren Sie IP-Adressen, die die Schwellenwerte für fehlgeschlagene Authentifizierungen überschreiten, deaktivieren Sie vorübergehend Konten, bei denen keine Übertragung möglich ist, und warnen Sie bei Massendatenzugriffsmustern.

---

Häufig gestellte Fragen

Sollte ich API-Schlüssel oder OAuth2-Tokens verwenden?

Verwenden Sie OAuth2-Tokens für jede API, die benutzerorientierte Anwendungen oder Integrationen von Drittanbietern bereitstellt. API-Schlüssel sind nur für die Server-zu-Server-Kommunikation akzeptabel, bei der beide Endpunkte unter Ihrer Kontrolle stehen, und selbst dann bieten HMAC-signierte Anfragen eine höhere Sicherheit. Verwenden Sie niemals API-Schlüssel als alleinige Authentifizierung für öffentlich zugängliche Endpunkte.

Wie gehe ich sicher mit der API-Versionierung um?

Verwenden Sie für Klarheit und Auffindbarkeit eine URL-basierte Versionierung (z. B. /api/v2/orders). Wenn Sie eine Version verwerfen, legen Sie ein Ablaufdatum fest, teilen Sie es den Verbrauchern mit und überwachen Sie die Nutzung. Wenden Sie weiterhin Sicherheitspatches auf veraltete Versionen an, bis diese vollständig eingestellt werden. Lassen Sie niemals ungepatchte alte API-Versionen laufen – sie werden zu leichten Zielen.

Welche Ratenlimits sollte ich für eine Business-API festlegen?

Beginnen Sie konservativ und steigern Sie die Leistung auf der Grundlage legitimer Nutzungsdaten. Für Authentifizierungsendpunkte sind 5–10 Anfragen pro Minute und IP Standard. Bei Datenendpunkten decken 100–500 Anfragen pro Minute und authentifiziertem Benutzer die meisten Geschäftsanwendungsfälle ab. Überwachen Sie 429 Antworten, um zu restriktive Grenzwerte zu erkennen, und überwachen Sie Missbrauchsmuster, um zu großzügige Grenzwerte zu erkennen.

Wie schütze ich Webhooks vor Drittanbieterdiensten?

Überprüfen Sie Webhook-Signaturen mithilfe von HMAC-SHA256 mit einem gemeinsamen Geheimnis. Validieren Sie den Zeitstempel, um Replay-Angriffe zu verhindern (Ereignisse, die älter als 5 Minuten sind, ablehnen). Verarbeiten Sie Webhooks asynchron, um einen Timeout-basierten Denial-of-Service zu verhindern. Protokollieren Sie alle Webhook-Ereignisse zu Prüfzwecken. Validieren Sie das Nutzlastschema vor der Verarbeitung.

---

Was kommt als nächstes?

API-Sicherheit ist keine Funktion, die Sie am Ende der Entwicklung hinzufügen – es ist ein Designprinzip, das vom ersten Endpunkt an vorhanden sein muss. Beginnen Sie mit einer starken Authentifizierung (OAuth2/OIDC), erzwingen Sie die Autorisierung an jedem Ressourcenzugriffspunkt, implementieren Sie eine Ratenbegrenzung für alle Endpunkttypen und validieren Sie jede Eingabe, die Ihre API-Grenze überschreitet.

ECOSIRE integriert Sicherheit in jede API-Integration. Unsere OpenClaw AI-Plattform implementiert standardmäßig HMAC-signierte Anfragen, Ratenbegrenzung und SSRF-Schutz, während unsere Odoo ERP-Integrationen OAuth2/OIDC mit rollenbasierter Zugriffskontrolle verwenden. Kontaktieren Sie unser Team, um die APIs Ihrer Geschäftsplattform zu sichern.

---

Veröffentlicht von ECOSIRE --- unterstützt Unternehmen bei der Skalierung mit KI-gestützten Lösungen in Odoo ERP, Shopify eCommerce und OpenClaw AI.