APIs absichern

Eine API ist eine offen erreichbare Tür in die Daten Ihres Unternehmens. Anders als bei klassischen Webanwendungen, bei denen ein Browser die Standardsicherheit übernimmt, kommt ein API-Konsument oft aus dem Nichts: ein Skript, ein anderer Server, eine mobile App, ein automatisierter Angreifer. Wer eine API ohne klare Sicherheitskonzepte ins Netz stellt, lädt Probleme aktiv ein — Datenabflüsse, Denial-of-Service, manipulierte Bestellungen oder Spam-Versand über die eigene Infrastruktur.

API-Sicherheit ist deshalb kein nachgelagertes Feature, sondern Teil des Architekturentwurfs. Wer sie früh einplant, bekommt sie zu einem Bruchteil der Kosten, die ein nachträglicher Einbau verursachen würde.

Sichere APIs ruhen auf drei tragenden Bereichen — alle drei müssen funktionieren:

Die wichtigsten Verfahren in der Praxis — sortiert nach Einsatzbereich:

• API-Keys. Ein einfacher Token, der mit jeder Anfrage mitgeschickt wird. Geeignet für Partner-APIs, Server-zu-Server-Kommunikation und einfache Anwendungsfälle. Vorsicht: API-Keys sollten niemals im Frontend-Code stehen.
• OAuth 2.0. Standard für Drittanbieter-Zugang. Ein Nutzer erlaubt einer App, in seinem Namen auf eine API zuzugreifen — ohne das eigene Passwort weiterzugeben. Komplexer im Setup, aber unverzichtbar bei Anwendungen mit Endnutzer-Berechtigungen.
• JWT (JSON Web Token). Ein signierter Token, der Identitäts- und Berechtigungs-Informationen direkt enthält. Skaliert gut, weil keine Session-Datenbank nötig ist. Vorsicht beim Token-Widerruf — JWTs sind bis zum Ablauf gültig.
• Session-basierte Authentifizierung. Klassisches Login mit Cookie, häufig bei Browser-Frontends auf derselben Domain. Einfach und sicher — aber weniger flexibel als Token-basierte Verfahren.
• mTLS (Mutual TLS). Beide Seiten weisen sich über Zertifikate aus. Sehr sicher, oft im B2B- und Bankenumfeld. Hoher Setup-Aufwand.
• HMAC-Signaturen. Anfragen werden mit einem geteilten Geheimnis signiert. Sicher gegen Replay-Angriffe, in Webhook-Szenarien häufig eingesetzt.

Welches Verfahren passt, hängt von Konsument, Schutzbedarf und Kontext ab. Häufig kombinieren reale Projekte mehrere Verfahren — etwa OAuth für Endnutzer und API-Keys für Server-zu-Server.

Authentifizierung allein reicht nicht. Eine sichere API berücksichtigt weitere Aspekte:

• Autorisierungs-Modell. Welche Rolle darf welche Aktionen? Idealerweise als zentral verwaltete Logik, nicht in jeden Endpunkt eingewoben.
• Rate-Limiting. Pro API-Key, IP-Adresse oder Nutzer — wie viele Anfragen pro Minute, pro Stunde, pro Tag? Schützt gegen Missbrauch und unabsichtliche Lawinen.
• Eingabe-Validierung. Jeder Parameter, jeder Body, jeder Header wird geprüft. Falsche Typen, fehlende Pflichtfelder, unrealistische Werte werden abgelehnt — mit klaren Fehlermeldungen.
• Output-Filterung. Nur die Daten zurückgeben, die der Konsument sehen darf. Niemals interne IDs, Passwort-Hashes oder Debug-Informationen versehentlich mitliefern.
• HTTPS — selbstverständlich, aber wichtig. Eine API ohne TLS ist im Jahr 2026 keine API mehr, sondern ein Datenleck.
• CORS sauber konfigurieren. Welche Browser-Origins dürfen die API aufrufen? Pauschale *-Freigaben gehören nicht in Produktion.
• Sicherheits-Header. Content-Security-Policy, X-Frame-Options, Strict-Transport-Security — auch APIs profitieren davon.
• Logging und Monitoring. Wer hat wann was aufgerufen, mit welchem Status, mit welcher Latenz? Auffällige Muster früh erkennen.

Aus der Praxis: Schwachstellen, die in API-Projekten immer wieder auftauchen:

• Broken Object Level Authorization. Konsument A kann mit einer geänderten URL auf die Daten von Konsument B zugreifen, weil nur die Authentifizierung geprüft wird, nicht die Eigentumsverhältnisse. Häufigster Fund bei Sicherheits-Audits.
• Übermäßige Datenpreisgabe. Eine API gibt mehr Felder zurück, als das Frontend braucht — und Angreifer lesen interne Informationen mit.
• Fehlendes Rate-Limiting. Ein Skript kann beliebig viele Anfragen senden — bis der Server zusammenbricht oder Kontodaten durch Brute-Force ausgelesen werden.
• Geheimnisse im Frontend. API-Keys, Tokens oder OAuth-Secrets im JavaScript-Code, der für jeden Browser sichtbar ist. Niemals tun.
• Verzichtbare Endpunkte aktiv. Test-, Debug- oder veraltete Endpunkte werden mit ausgeliefert, weil sie niemand gelöscht hat. Werden zum Einfallstor.
• Schwache Fehlerbehandlung. Stack-Traces oder Datenbank-Fehler in Response-Bodies geben Angreifern wertvolle Hinweise auf die innere Struktur.
• Veraltete Bibliotheken. Frameworks und Dependencies werden nicht aktualisiert — bekannte Schwachstellen bleiben offen.

Ein bewährter Ansatz für API-Sicherheit in mittelständischen Projekten:

1. Schutzbedarf klären. Welche Daten, welche Konsumenten, welche Folgen bei Missbrauch? Diese Frage entscheidet darüber, wie weit Sicherheit getrieben werden muss.
2. Authentifizierung früh festlegen. Welches Verfahren passt zum Anwendungsfall? Nicht erst beim Go-Live entscheiden.
3. Autorisierung als zentrales Konzept. Rollen, Berechtigungen und Datenzugriffe sauber strukturieren — nicht ad hoc pro Endpunkt.
4. Rate-Limiting und Validierung als Standard. Von Anfang an, nicht nachträglich.
5. Logging und Monitoring von Tag eins. Damit Auffälligkeiten erkannt werden, bevor sie zum Problem werden.
6. Regelmäßige Updates und Audits. Dependencies aktuell halten, Logs sichten, ungenutzte Endpunkte entfernen.

Wer diese Schritte konsequent umsetzt, hat eine API, die nicht nur funktioniert, sondern auch im Ernstfall keine bösen Überraschungen produziert.