Cloud, QA & Sicherheit

API-Sicherheitstests für REST und GraphQL

Gjethe testet APIs direkt, so wie Angreifer es tun: Autorisierung für jedes Objekt, Authentifizierung, wie viele Daten Antworten zurückgeben, Mass Assignment, Ratenlimits und Geschäftsabläufe. Die Tests folgen den OWASP API Security Top 10, und jeder Befund kommt mit Belegen, einer Korrektur und einem Nachtest.

  • Kostenlose Erstberatung
  • Schriftliches Angebot für Ihr Projekt
  • Flexible Zahlungsmeilensteine
✓ build passed

Auf einen Blick

API-Typen
REST, GraphQL, WebSocket
Standard
OWASP API Security Top 10
Schwerpunkt
Autorisierung, Datenpreisgabe, Rate Limits
Ausgabe
Bericht, Korrekturen und Nachtest

Definition

Was ist API-Sicherheitstest?

API-Sicherheitstests sind die Bewertung einer Programmierschnittstelle auf Schwachstellen, die Aufrufern den Zugriff auf Daten oder Funktionen erlauben, die sie nicht haben sollten, indem gezielt gebaute Anfragen direkt an ihre Endpunkte gesendet werden.

Mobile Apps, Single-Page-Web-Apps, Partner und Integrationen sprechen alle mit Ihrer API. Die Oberfläche mag Felder und Schaltflächen verbergen, aber die API antwortet jedem, der die richtige Anfrage sendet. Deshalb legen APIs oft mehr offen als beabsichtigt: vollständige Datensätze, wenn die App nur einen Namen zeigt, Aktionen, die durch Ändern einer Adresse erreichbar sind, oder keine Begrenzung, wie schnell jemand Logins versuchen oder Daten abziehen kann. API-Tests lassen die Oberfläche beiseite und prüfen, was der Server selbst erlaubt.

Für wen ist es geeignet?

  • Teams mit öffentlicher oder Partner-API

    Alles, was anderen Entwicklern zugänglich ist, ist jedem zugänglich, der Ihre Doku liest.

  • Backends mobiler Apps

    Die App ist nur ein Client; die API muss sich gegen jede Anfrage selbst verteidigen.

  • Microservice-Architekturen

    Interne Dienste vertrauen einander oft zu sehr; wir prüfen diese Grenzen.

  • Produkte mit Zahlungen oder Guthaben

    Geld, Guthaben und Kontingente sind bevorzugte Ziele für Logik- und Rate-Limit-Missbrauch.

Was enthalten ist und was Sie behalten

Was enthalten ist

  • Prüfung von API-Dokumentation und Schema
  • Erkennung von Endpunkten und Operationen
  • Tests der Autorisierung auf Objektebene
  • Tests der Autorisierung auf Funktionsebene
  • Prüfung von Authentifizierung und Token-Handling
  • Prüfungen auf übermäßige Datenpreisgabe
  • Tests auf Mass Assignment und Eingabeverarbeitung
  • Tests von Rate Limiting und Ressourcenmissbrauch
  • Tests von Geschäftsabläufen und Reihenfolgen
  • GraphQL-spezifische Prüfungen, wo relevant
  • Prüfung von Transport und Konfiguration
  • Bericht mit Nachweisen, Korrekturen und Nachtest

Was Sie erhalten

Wird am Ende übergeben. Gehört Ihnen.

  • Bericht zum API-Sicherheitstest
  • Befunde den OWASP API Top 10 zugeordnet
  • Klare Beschreibung jedes bestätigten Problems
  • Korrekturempfehlungen pro Befund
  • Nachtestbericht

OWASP-API-Security-Top-10-Bereiche, die wir abdecken

BereichBeispiel für das, was wir prüfen
Fehlerhafte Autorisierung auf ObjektebeneDen Datensatz eines anderen Nutzers lesen, indem man eine Kennung ändert
Fehlerhafte AuthentifizierungSchwache Tokens, fehlender Ablauf, erratbare Zugangsdaten
Fehlerhafte Autorisierung auf ObjekteigenschaftsebeneFelder setzen, die der Aufrufer nicht kontrollieren sollte
Uneingeschränkter RessourcenverbrauchKeine Rate Limits bei aufwendigen oder sensiblen Operationen
Fehlerhafte Autorisierung auf FunktionsebeneAdmin-Operationen als normaler Nutzer aufrufen
Uneingeschränkter Zugriff auf GeschäftsabläufeEinen Ablauf automatisieren, der nur einmal gedacht war
Server-Side Request ForgeryDie API ruft Adressen ab, die ein Aufrufer kontrolliert
SicherheitsfehlkonfigurationAusführliche Fehler, Debug-Endpunkte, lockere Einstellungen
Unsachgemäßes BestandsmanagementVergessene alte Versionen, die weiter Anfragen annehmen
Unsichere Nutzung von DrittanbieternDaten einer externen API ohne Prüfung vertrauen

Warum APIs mehr preisgeben, als die App zeigt

Eine Webseite zeigt einem Kunden seinen eigenen Namen und nichts weiter. Die Anfrage dahinter liefert aber vielleicht den ganzen Nutzerdatensatz zurück, einschließlich Feldern, die die Seite stillschweigend ignoriert. Angreifer lesen Antworten direkt, daher ist alles, was der Server sendet, faktisch öffentlich für jeden, der den Endpunkt aufrufen kann.

Wir testen von der Seite des Aufrufers: Jeder Endpunkt wird als verschiedene Nutzer und Rollen aufgerufen, mit geänderten Kennungen und Feldern, um zu sehen, ob der Server prüft, wer fragt, und nur zurückgibt, was derjenige sehen darf. GraphQL bekommt besondere Aufmerksamkeit, weil eine einzige flexible Abfrage weit mehr erreichen kann als eine feste REST-Route, wenn die Regeln nicht pro Feld durchgesetzt werden.

Warum APIs eigene Tests brauchen

Man nimmt leicht an, dass der Test der Website auch die API dahinter testet. Das tut er nicht. Die Website nutzt die API so, wie ihre Designer es vorgesehen haben, über die Schaltflächen und Bildschirme, die sie gebaut haben. Ein Angreifer ignoriert all das und ruft die Endpunkte direkt auf, in beliebiger Reihenfolge, mit beliebigen Werten, als jedes Konto, das er bekommen kann. Ganze Problemkategorien zeigen sich nur aus diesem Blickwinkel: ein Endpunkt, der einer Nutzer-ID aus der Anfrage vertraut, ein Feld, das schreibgeschützt sein sollte, aber beschreibbar ist, eine Operation ohne Begrenzung, wie oft sie laufen darf.

Die API für sich zu testen schützt außerdem jeden Client, der von ihr abhängt. Eine einzelne API bedient meist eine Web-App, eine mobile App und oft gleichzeitig Partnerintegrationen. Eine Schwäche dort betrifft alle, daher schützt die Behebung auf API-Ebene das ganze Produkt statt eines Bildschirms.

So funktioniert API-Sicherheitstesting, Schritt für Schritt

Jeder Schritt hat ein klares Ergebnis, das Sie prüfen können. Der Zeitrahmen wird in Ihrem Angebot vereinbart.

  1. 1

    Umfang

    APIs, Umgebungen, Rollen und Testzugangsdaten schriftlich abgestimmt.

  2. 2

    Karte

    Endpunkte, Operationen und Rollen aus Dokumentation und Traffic erfasst.

  3. 3

    Testen

    Autorisierung, Authentifizierung, Datenpreisgabe und Missbrauch von Hand getestet.

  4. 4

    Verifizieren

    Jeder Befund sorgfältig mit ungefährlichem Nachweis bestätigt.

  5. 5

    Bericht

    Befunde den API Top 10 zugeordnet, mit Korrekturen.

  6. 6

    Nachtest

    Korrekturen verifiziert und Bericht aktualisiert.

Tools und was Ihr Angebot beeinflusst

Die Preisgestaltung richtet sich nach Ihrem Projekt und wird in Ihrem Angebot vereinbart. Diese Faktoren bestimmen es.

API-Sicherheitstests: Preisfaktoren
FaktorWarum er wichtig ist
Anzahl der EndpunkteMehr Operationen bedeuten mehr Autorisierungs- und Eingabetests.
Anzahl der RollenJede Rolle muss gegen jede sensible Operation getestet werden.
REST vs. GraphQLGraphQL braucht Prüfungen pro Feld und Tests der Abfragekosten.
Qualität der DokumentationGute Schemas und Collections machen Tests schneller und vollständiger.
GeschäftsabläufeZahlungen, Kontingente und mehrstufige Abläufe brauchen sorgfältige Logiktests.

Häufige Fehler, die Sie vermeiden sollten

Was bei uns am häufigsten schiefgeht und wie ein gutes Projekt es vermeidet.

  • Berechtigungen nur in der App prüfen

    Wenn die API nicht bei jeder Anfrage erneut prüft, bedeuten die Einschränkungen der App nichts.

  • Ganze Objekte zurückgeben

    Vollständige Datensätze zu senden und den Client Felder auswählen zu lassen, legt jedem alles offen, der Antworten mitliest.

  • Keine Ratenlimits

    Ohne Limits lassen sich Logins erraten und Daten massenhaft abziehen.

  • Vergessene alte Versionen

    Alte API-Versionen, die weiterlaufen, haben oft die Korrekturen nicht, die der aktuellen hinzugefügt wurden.

Häufig gestellte Fragen

Brauchen Sie unsere API-Dokumentation?

Sie hilft sehr. Ein Schema, eine Postman-Collection oder eine OpenAPI- bzw. GraphQL-Definition beschleunigt das Testen und verbessert die Abdeckung. Wo sie fehlt, kartieren wir Endpunkte anhand des Verkehrs Ihrer Clients.

Können Sie eine GraphQL-API testen?

Ja. GraphQL braucht Autorisierungsprüfungen pro Feld und Tests der Abfragekosten, die wir neben den üblichen API-Bereichen abdecken.

Beeinträchtigt das Testen unsere Produktivdaten?

Wir bevorzugen eine Staging-Umgebung mit Testdaten. Wenn wir die Produktion testen müssen, nutzen wir Testkonten, vereinbaren Zeitfenster und vermeiden Aktionen, die echte Datensätze verändern.

Testen Sie Authentifizierungsanbieter wie OAuth?

Wir testen, wie Ihre API Tokens und Sitzungen nutzt: Ablauf, Scope, Validierung und Behandlung. Der Identitätsanbieter selbst liegt meist außerhalb des Umfangs, es sei denn, Sie betreiben ihn.

Wie unterscheidet sich das von einem Web-App-Test?

Ein Web-App-Test arbeitet über die Oberfläche; ein API-Test arbeitet direkt gegen Endpunkte, dort, wo sich mobile Apps, Integrationen und Single-Page-Apps tatsächlich verbinden.

Ist ein Nachtest enthalten?

Ja. Nachdem Sie die Befunde behoben haben, testen wir sie erneut und aktualisieren den Bericht.

Können Sie bei der Behebung der Befunde helfen?

Ja. Unsere Entwickler können die Korrekturen umsetzen oder die Änderungen Ihres Teams vor dem Nachtest prüfen.

Unterschreiben Sie eine NDA?

Ja. Befunde sind vertraulich und werden nur den von Ihnen genannten Kontakten zugänglich gemacht; Testdaten werden danach entfernt.

Testen Sie auch ältere API-Versionen?

Ja, wenn sie im Umfang liegen. Weiterlaufende alte Versionen sind eine häufige Schwachstelle, weil Korrekturen der aktuellen Version dort oft nie angewendet werden.

Was brauchen Sie von uns zum Start?

Die Basisadresse jeder API, Zugangsdaten für jede Rolle, vorhandene Schemas oder Dokumentation und einen benannten Ansprechpartner, falls während des Tests etwas Aufmerksamkeit braucht.

Sehen Sie, was Ihre API wirklich erlaubt.

Sagen Sie uns, was Sie brauchen. Sie erhalten eine ehrliche Einschätzung, einen klaren Plan und ein schriftliches Angebot. Die erste Beratung ist immer kostenlos.

  1. Wie es weitergeht
  2. 1Sie sagen uns, was Sie brauchen
  3. 2Wir melden uns möglichst innerhalb von 24 Stunden mit Rückfragen
  4. 3Sie erhalten ein schriftliches Angebot für Ihr Projekt