TL; DR
Die meisten API-Sicherheitsvorfälle lassen sich auf fehlerhafte Autorisierung und nicht auf exotische Exploits zurückführen. Drei der fünf wichtigsten Kategorien der OWASP API Security Top 10 sind Autorisierungsfehler, angeführt von BOLA.
Man kann nicht sichern, was man nicht einmal kennt. Unsachgemäße Bestandsverwaltung ist eine eigene OWASP-Risikokategorie und die Grundlage, auf der alle anderen Kontrollmaßnahmen aufbauen.
Gefährdungspotenzial vor dem Einsatz erkennen, nicht danach. Die statische Analyse von Code und API-Spezifikationen findet einen fehlerhaften Endpunkt in einem pull requestzum Preis von einem commit; Laufzeittests decken dasselbe Problem auch im Live-Betrieb auf, was die Kosten eines Vorfalls verursacht.
Dies ist eine Checkliste, die kontinuierlich ausgeführt werden soll. Auf jedem pull request, keine Vorab-Rezension: 10 PraktikenVon Bestandsaufnahme und Autorisierung bis hin zu Ratenbegrenzung, Offenlegung von Antwortdaten und Vertrauen in Dritte.
Mit jedem Tag wächst die Angriffsfläche Ihrer API. pull requestDie meisten Teams bemerken eine Sicherheitslücke an einem Endpunkt erst, wenn dieser in Betrieb ist und Datenverkehr verarbeitet, was bedeutet, dass die Behebung, die sonst einen Mitarbeiter gekostet hätte, … commit Die Überprüfung kostet nun einen Vorfallbericht. Dieser Leitfaden führt Sie durch die bewährten Methoden der API-Sicherheit, die sich in der Praxis bewähren. Er ist als Checkliste aufgebaut, die Sie sofort an Ihrem eigenen Code anwenden können – keine Liste abstrakter Prinzipien, die niemand umsetzt.
Warum die Best Practices für API-Sicherheit heute anders aussehen
APIs waren einst das Bindeglied zwischen Systemen. Heute sind sie die primäre Schnittstelle für nahezu alles: mobile Apps, Partnerintegrationen, KI-Systeme und interne Microservices. Diese Entwicklung hat die Anforderungen an den API-Schutz grundlegend verändert. Es reicht nicht mehr aus, nur die dokumentierten APIs abzusichern; auch die von Teams entwickelten, aber nicht dokumentierten APIs müssen berücksichtigt werden.
Zwei Zahlen erklären, warum das wichtig ist. OWASP API-Sicherheit Top 10 Fehlerhafte Autorisierungsprobleme zählen zu den fünf wichtigsten Risikokategorien. Das bedeutet, dass die meisten API-Vorfälle in der Praxis auf wenige vermeidbare Muster zurückzuführen sind und nicht auf seltene Zero-Day-Schwachstellen. Auch unzureichendes Bestandsmanagement gehört zu dieser Risikokategorie: Teams werden über APIs angegriffen, von denen sie nicht wussten, dass sie noch aktiv sind.
Das ist das Leitmotiv, das sich durch alle folgenden Punkte zieht. Gute API-Management-Best Practices beginnen damit, zu wissen, was man hat, und nicht nur das zu verteidigen, was man dokumentiert hat.
API-Sicherheit – Bewährte Verfahren im Überblick
Bevor wir zur detaillierten Checkliste kommen, hier die Kurzfassung: Was umgesetzt werden soll, wovor es tatsächlich schützt und wie dringend.
Die Zeile „Erforderlich“ ist als unabdingbare Grundlage für jede API, ob intern oder öffentlich, zu betrachten. Die Elemente mit „Hoher Priorität“ sind das, was ein Programm auszeichnet, das Probleme frühzeitig erkennt. pull request von jemandem, der es in einem Vorfallsbericht erfährt.
Checkliste für bewährte Verfahren zur API-Sicherheit
1. Stelle ein vollständiges Inventar zusammen, bevor du eine Verteidigungsanlage baust.
Sie können einen Endpunkt nicht schützen, von dessen Existenz Sie nichts wissen. Beginnen Sie jede Maßnahme zur API-Sicherheit mit einer vollständigen Bestandsaufnahme: Jeder Endpunkt, seine Methode, sein Pfad, der zugehörige Dienst und das Modul sowie die Information, ob eine Authentifizierung erforderlich ist. Diese Informationen sollten Sie sowohl aus dem Quellcode als auch aus Ihren API-Spezifikationen (OpenAPI, Swagger) gewinnen, nicht nur aus der Dokumentation. Denn genau in der Lücke zwischen beiden verstecken sich vergessene und verwaiste Endpunkte.
Wo Xygeni passt: Xygeni API-Sicherheit Erstellt dieses Inventar direkt aus Ihrem Anwendungsquellcode und Ihren API-Spezifikationen und zeigt die Endpunkte an, die Ihr Team dokumentiert hat, sowie diejenigen, die niemand dokumentiert hat, bevor einer von ihnen in die Produktion gelangt.
2. Autorisierung auf Objekt- und Funktionsebene durchsetzen
Fehlerhafte Autorisierung auf Objekt- und Funktionsebene führen regelmäßig die OWASP API Security Top 10 an. Die beste Vorgehensweise ist nicht, „Authentifizierung hinzuzufügen“, sondern bei jeder Anfrage zu prüfen, ob dieser spezielle Benutzer ist der Zugriff gestattet dieses spezielle ObjektEs geht nicht nur darum, ob sie überhaupt angemeldet sind. Die Authentifizierung klärt, wer jemand ist. Die Autorisierung klärt, worauf sie zugreifen darf, und das muss jedes Mal überprüft werden; es darf nicht automatisch durch ein gültiges Token vorausgesetzt werden.
3. Alle von der API empfangenen Daten validieren und bereinigen.
Alle Parameter, Header und Body-Felder gelten als nicht vertrauenswürdige Eingaben, bis das Gegenteil bewiesen ist. Erzwingen Sie eine strikte Schema-Validierung, weisen Sie unerwartete Felder zurück (dies schützt Sie vor Massenzuweisungen) und vertrauen Sie niemals clientseitigen Daten zur Bestimmung des Zugriffsbereichs oder der Preislogik.
4. Ratenbegrenzung und Drosselung von vornherein planen, nicht nachträglich einbauen.
Ungezügelter Ressourcenverbrauch kann dazu führen, dass ein einzelner Client Ihre Infrastruktur überlastet oder die Kosten für nutzungsbasierte Backend-Dienste in die Höhe treibt. Legen Sie Limits pro Endpunkt, pro Benutzer und pro API-Schlüssel fest und stellen Sie sicher, dass diese Limits mit den tatsächlichen Betriebskosten skalieren und nicht pauschal für alle gelten.
5. Behandeln Sie jede Antwort als potenzielles Datenleck.
Eine übermäßige Datenweitergabe liegt vor, wenn eine API mehr Daten zurückgibt, als der Client benötigt, und sich auf das Frontend verlässt, um diese zu filtern. Dies ist eine gängige Praxis und kein seltener Fehler. Es handelt sich dabei um einen der häufigsten Verstöße gegen die Best Practices für den API-Schutz, da er erst dann auffällt, wenn jemand die Rohdaten der API-Antworten anstatt der gerenderten Benutzeroberfläche untersucht.
Wo Xygeni passt: Xygeni API Security kennzeichnet die Offenlegung personenbezogener Daten direkt in API-Antworten und erkennt so übermäßige Weitergabe, bevor die API ausgeliefert wird, anstatt erst, nachdem ein Kunde oder eine Aufsichtsbehörde davon Kenntnis erlangt hat.
6. Führen Sie ein genaues und aktuelles API-Inventar, einschließlich der veralteten APIs.
Falsch Inventar API-Management ist aus gutem Grund eine eigene Kategorie in der OWASP-Liste: Veraltete API-Versionen und undokumentierte Testumgebungen sind oft noch erreichbar und häufig auch dann noch angreifbar, wenn sich niemand mehr an ihre Existenz erinnert. Ein Best-Practice-Programm für API-Management muss daher nicht nur die Ermittlung, sondern auch die Außerbetriebnahme umfassen.
7. Prüfen Sie genau, welchen Drittanbietern Ihre API vertraut.
Die unsichere Nutzung von Drittanbieter-APIs ist ein unterschätztes Risiko. Entwickler neigen dazu, Daten aus anderen APIs mehr zu vertrauen als Benutzereingaben – ein fataler Irrtum. Eine Drittanbieterintegration ist und bleibt eine externe, ungeprüfte Quelle und sollte daher genauso validiert werden.
8. Legen Sie den Entwicklern Beweise vor, nicht nur Warnmeldungen.
Eine Fehlermeldung wie „Autorisierungsfehler an diesem Endpunkt“ erfordert eine Untersuchung, bevor das Problem behoben werden kann. Eine Fehlermeldung, die die genaue Datei, Klasse, Methode und Zeile angibt, ermöglicht es Entwicklern, sofort Maßnahmen zu ergreifen. Dies ist eine bewährte Vorgehensweise für das gesamte Sicherheitsprogramm, nicht nur für die API: Fehlermeldung, die vor der Behebung untersucht werden muss, verlangsamt den gesamten Prozess.
Wo Xygeni passt: Jeder Sicherheitsbefund von Xygeni API verweist auf den genauen Handler, die Datei, die Klasse, die Methode und die Zeile, in der er eingeführt wurde, sodass die Behebung in dem Moment beginnt, in dem der Befund auftritt.
9. Schwachstellen vor dem Einsatz ermitteln, nicht danach.
Laufzeit-API-Tests zeigen, dass ein Endpunkt offengelegt ist, sobald er bereits Datenverkehr verarbeitet. Statische Code- und API-Spezifikationsanalysen decken dieselbe Offenlegung auf, solange sich der Endpunkt noch im Betrieb befindet. pull requestwenn die Reparatur eins kostet commit Anstelle einer Reaktion auf einen Vorfall. Die besten Best Practices im API-Management sehen die statische Erkennung als erste Ebene vor, während Laufzeittests als zweite, ergänzende Überprüfung dessen dienen, was bereits live ist.
Wo Xygeni passt: Xygeni API Security ist von Grund auf statisch, analysiert Code und Spezifikationen vor der Veröffentlichung und arbeitet mit Xygeni DAST zur Laufzeitabdeckung von Anwendungen, die sich bereits im Produktivbetrieb befinden.
10. Behandeln Sie API-Risiken am selben Ort wie die übrigen Anwendungsrisiken.
APIs versagen nicht isoliert. Eine API-Schwachstelle tritt häufig als Folge eines Abhängigkeitsproblems oder einer Fehlkonfiguration auf. pipelineoder ein durchgesickertes Geheimnis. API-Sicherheit als separates Tool mit eigener Konsole zu behandeln, bedeutet, diesen Kontext genau dann zu verlieren, wenn es am wichtigsten ist.
Wo Xygeni passt: API-Sicherheit ist eng verbunden SAST, SCA, Geheimnisse, IaCund DAST auf einer einzigen Xygeni-Plattform, sodass ein API-Befund neben dem Code und dem Abhängigkeitsrisiko, das ihn verursacht hat, sichtbar ist und nicht in einem separaten login.
Die Checkliste zur Gewohnheit machen
Die Best Practices für API-Sicherheit funktionieren nur als kontinuierliche Maßnahme, nicht als Überprüfung vor dem Launch. Führen Sie eine Bestandsaufnahme und statische Analyse für jede Anwendung durch. pull requestNicht nur einmal im Quartal. Behandeln Sie einen neuen, undokumentierten Endpunkt genauso wie eine neue, undokumentierte Abhängigkeit: als etwas, das sofort untersucht werden muss, nicht irgendwann. Und messen Sie Ihre Best Practices für den API-Schutz genauso wie jeden anderen Teil des Systems. SDLCEs kommt darauf an, wie früh man das Problem erkennt, nicht nur darauf, ob man es überhaupt bemerkt hat.
Kurzantworten: Fragen und Antworten zu Best Practices für API-Sicherheit
Wichtige Erkenntnisse
- Die Bestandssicherung geht vor der Verteidigung. Man kann keine Autorisierung, Ratenbegrenzungen oder Datenkontrollen auf einen Endpunkt anwenden, von dessen Existenz man nichts weiß, und unsachgemäße Bestandsverwaltung ist ein eigenes, benanntes Risiko in den OWASP API Security Top 10.
- Die meisten Sicherheitslücken entstehen bei der Autorisierung, nicht nur bei der Authentifizierung. Drei der fünf größten API-Sicherheitsrisiken laut OWASP sind Autorisierungsfehler. Die Identität einer Person zu überprüfen ist nicht dasselbe wie zu überprüfen, worauf diese Person Zugriff hat.
- Die statische Analyse deckt auf, was Laufzeittests zu spät erkennen. Auffinden von Expositionen in einem pull request kostet eins commit. Das Auffinden während der Produktion verursacht einen Zwischenfall.
- Jede Antwort birgt das Potenzial für ein Datenleck. Übermäßiger Umgang mit Daten ist eine Gewohnheit, kein seltener Fehler, und er bleibt unsichtbar, bis jemand die Rohdaten der API-Antworten anstelle der gerenderten Benutzeroberfläche untersucht.
- Die besten Praktiken für API-Sicherheit funktionieren nur, wenn sie kontinuierlich angewendet werden., läuft auf jedem pull request, keine vierteljährliche Überprüfung oder Checkliste vor dem Marktstart.
- API-Risiken sollten nicht in einem separaten Tool isoliert werden. Die nützlichsten Best Practices zum Schutz von APIs behandeln API-Ergebnisse als Teil desselben Risikobildes wie Code, Abhängigkeiten und pipeline security, keine isolierte Konsole.
FAQ
Was sind die wichtigsten Best Practices für API-Sicherheit, mit denen man beginnen sollte?
Beginnen Sie mit der Bestandsaufnahme. Autorisierungsprüfungen, Ratenbegrenzungen oder Kontrollen der Datenexposition können nicht auf einen Endpunkt angewendet werden, von dessen Existenz Sie nichts wissen. Daher ist eine vollständige und genaue Bestandsaufnahme aller API-Endpunkte die Grundlage für alles andere auf dieser Checkliste.
Worin besteht der Unterschied zwischen Best Practices für API-Sicherheit und allgemeinen Best Practices für Anwendungssicherheit?
APIs bergen Risiken, die allgemeine AppSec-Praktiken nicht vollständig abdecken: die Autorisierung auf Objekt- und Funktionsebene in großem Umfang, die spezifische Gefahr, API-Antworten von Drittanbietern zu vertrauen, und die Herausforderung, veraltete oder undokumentierte Endpunkte zu verfolgen. Best Practices für API-Sicherheit sind Best Practices für Anwendungssicherheit, angewendet auf die Teile der Angriffsfläche, die am leichtesten zu übersehen sind.
Sollte die API-Sicherheitsprüfung vor oder nach der Bereitstellung erfolgen?
Beides ist wichtig, aber der entscheidende Punkt liegt vorher. Die statische Analyse von Code und API-Spezifikationen deckt Schwachstellen auf, solange sie noch vorhanden sind. pull requestLaufzeittests (DAST) überprüfen anschließend, was tatsächlich erreichbar ist, sobald die Anwendung live ist. Sich ausschließlich auf Laufzeittests zu verlassen, führt dazu, dass jede Fehlerbehebung mehr kostet als nötig.
Wie oft sollte ein API-Inventar aktualisiert werden?
Kontinuierlich, idealerweise auf jeder pull requestEin einmal erstellter und vierteljährlich überprüfter Bestand ist bereits veraltet, sobald ein neuer Endpunkt ausgeliefert wird – genau diese Lücke nutzt eine mangelhafte Bestandsverwaltung aus.
Gelten Best Practices für das API-Management auch für interne APIs und nicht nur für öffentlich zugängliche?
Ja. Interne APIs unterliegen häufig niedrigeren Sicherheitsstandards, weil sie „nicht dem Internet ausgesetzt sind“, aber sie verarbeiten dennoch sensible Daten und sind für jeden mit internem Netzwerkzugriff erreichbar, einschließlich eines kompromittierten Kontos oder eines Insiders.
