API-Sicherheitstests: 10 Dinge, die jeder Anfaenger wissen muss

APIs sind die Grundlage nahezu jeder modernen Anwendung. Wenn Sie eine mobile App oeffnen, Ihren Kontostand pruefen, Essen bestellen oder Ihr Profil aktualisieren, arbeitet eine API im Hintergrund. Die Website ist der sichtbare Teil. Die API ist der Teil, der die Daten sendet, empfaengt und verarbeitet.

Genau deshalb sind APIs eines der wichtigsten Ziele fuer Sicherheitstests. Eine Website mag von aussen sicher aussehen, aber die dahinter liegende API kann dennoch private Daten offenlegen, was zu einer Datenschutzverletzung fuehrt, oder Aktionen des falschen Benutzers akzeptieren. Viele schwerwiegende API-Bugs werden nicht durch komplexe Payloads gefunden. Sie werden gefunden, indem man Anfragen sorgfaeltig liest, kleine Werte aendert und eine Frage stellt: Sollte dieser Benutzer dies tun duerfen?

Dieser Leitfaden fuehrt Sie durch alles, was Sie brauchen, um mit API-Sicherheitstests zu beginnen, von Grund auf.

1. Was ist API-Sicherheit und warum ist sie wichtig?

Fuer normale Benutzer ist die Anwendung der Bildschirm, den sie sehen. Fuer Sicherheitstester lebt die eigentliche Anwendung im API-Datenverkehr. Jeder Button-Klick, jede Profilaktualisierung, jeder Datei-Upload, jede Zahlungsaktion und jede Passwortaenderung erzeugt eine API-Anfrage.

Die API ist der Ort, an dem die sensibelsten Daten leben. Wenn eine API nicht ordnungsgemaess geschuetzt ist, kann das Frontend sie nicht retten. Ein Button kann ausgeblendet werden, aber die Anfrage kann trotzdem manuell gesendet werden. Ein Feld kann im Browser deaktiviert werden, aber es kann trotzdem in Burp Suite geaendert werden. Eine mobile App kann Daten auf dem Bildschirm verbergen, aber die vollstaendige API-Antwort kann sie trotzdem enthalten.

Die Regel ist einfach: Vertrauen Sie niemals nur dem, was die Benutzeroberflaeche anzeigt. Das Frontend ist die Praesentationsschicht. Echte Sicherheit muss auf der Serverseite stattfinden. Der Server muss pruefen, wer der Benutzer ist, worauf er zugreifen darf und ob die uebermittelten Daten vertrauenswuerdig sind.

Als Anfaenger ist das eine gute Nachricht. Sie brauchen keine hochentwickelten Exploitationstechniken. Wenn Sie Authentifizierung, Autorisierung, API-Antworten und grundlegende Anfragemodifikation verstehen, koennen Sie bereits damit beginnen, echte API-Sicherheitsprobleme zu finden.

2. Wie ein IDOR-Bug API-Sicherheitstests erklaert

Es war gegen 23 Uhr, als Arjun, ein angehender Bug-Bounty-Jaeger, eine Job-Recruiting-Plattform testete. Er hatte erst seit wenigen Monaten gelernt. Er erstellte ein Konto, loggte sich ein, oeffnete sein Profil und begann, die Anfragen in Burp Suite zu beobachten.

Eine Anfrage erregte seine Aufmerksamkeit. Der API-Endpunkt sah aus wie /api/v1/users/1147/profile. Die Antwort zeigte seine eigenen Profildetails: Name, E-Mail-Adresse, Telefonnummer und gespeicherte Adresse. Alles sah normal aus. Aber dann bemerkte er die Zahl in der URL. Sie sah aus wie eine Benutzer-ID.

Aus Neugier aenderte er 1147 zu 1148 und sendete die Anfrage erneut. Er erwartete einen Fehler. Vielleicht 403 Forbidden. Vielleicht 404 Not Found. Stattdessen gab die API das vollstaendige Profil eines anderen Benutzers zurueck. Er aenderte die Zahl erneut. Ein weiteres Profil kam zurueck.

Arjun hatte Broken Object Level Authorization gefunden, auch bekannt als BOLA oder IDOR. Die API pruefte, dass er eingeloggt war, aber sie pruefte nicht, ob das angeforderte Profil tatsaechlich zu ihm gehoerte. Dies ist einer der haeufigsten und gefaehrlichsten API-Sicherheitsfehler.

Die Lektion: Arjun benutzte keinen komplexen Exploit. Er umging keine Firewall. Er aenderte einfach einen Wert in einer API-Anfrage, und der Server gab Daten zurueck, die geschuetzt sein sollten.

Ich habe dieses exakte Muster hunderte Male in meinen ueber 250 Hall-of-Fame-Eintraegen gesehen. BOLA ist durchgehend der erste echte Bug, den meine Studenten finden, und sie bleibt die haeufigste IDOR-Schwachstelle in der Praxis. Die Technik ist einfach, aber die Auswirkung ist fast immer kritisch.

3. Die 6 Voraussetzungen vor dem Testen von APIs

Bevor Sie mit dem Testen von APIs beginnen, brauchen Sie ein Fundament. Sie muessen nicht alles beherrschen, aber Sie sollten verstehen, was passiert, wenn Sie eine Anfrage senden und eine Antwort erhalten.

1. Computerhardware und Netzwerke. Verstehen Sie, wie Geraete Netzwerke nutzen, um Daten auszutauschen. Lernen Sie, was IP-Adressen, DNS und Router tun. Machen Sie sich mit dem OSI-Modell vertraut.

2. Kommandozeile und Linux. Sie sollten mit grundlegenden Linux-Befehlen und einer Testdistribution wie Kali Linux vertraut sein. Lesen Sie Dateien, fuehren Sie Tools aus, senden Sie Anfragen und formatieren Sie JSON-Antworten. Lernen Sie grundlegendes Bash- oder Python-Scripting fuer die Automatisierung.

3. HTTP-Grundlagen. APIs arbeiten ueber HTTP-Anfragen. Eine Anfrage hat eine Methode, Header und manchmal einen Body oder Parameter. Kennen Sie die gaengigen Methoden: GET (lesen), POST (erstellen), PUT/PATCH (aktualisieren), DELETE (loeschen). Kennen Sie die Statuscodes: 200 (Erfolg), 401 (nicht autorisiert), 403 (verboten), 404 (nicht gefunden), 500 (Serverfehler).

4. Authentifizierung vs. Autorisierung. Authentifizierung bedeutet, zu beweisen, wer Sie sind, wie das Einloggen mit einem Passwort. Autorisierung bedeutet, zu entscheiden, was Sie nach dem Login tun duerfen. Ein normaler Benutzer und ein Administrator koennen beide eingeloggt sein, aber sie sollten nicht dieselben Berechtigungen haben. Viele schwerwiegende API-Bugs entstehen, weil Authentifizierung vorhanden ist, aber die Autorisierung schwach oder fehlend ist. Lernen Sie die gaengigen Typen: Basic, Token-basiert, JWT, Session, SSO und OAuth.

5. API-Typen und -Struktur. Eine API ist eine Moeglichkeit fuer zwei Systeme zu kommunizieren. Der Client sendet eine Anfrage, der Server sendet Daten zurueck, normalerweise im JSON-Format. Kennen Sie die Haupttypen: REST (am haeufigsten, verwendet Standard-URLs und HTTP-Methoden), GraphQL (einzelner Endpunkt, Client gibt genau an, welche Daten er will), SOAP (aelter, XML-basiert, wird noch im Bankwesen verwendet), WebSockets (Echtzeit-Kommunikation) und gRPC (schnell, modern, Service-zu-Service). Beginnen Sie mit REST, dann wechseln Sie zu GraphQL.

6. Burp Suite und Postman. Dies sind die wichtigsten Tools fuer API-Tests. Burp Suite ermoeglicht es Ihnen, Anfragen abzufangen, Werte zu aendern und Serverantworten zu beobachten. Postman hilft Ihnen, API-Anfragen manuell zu erstellen und zu organisieren. Verbringen Sie Zeit in diesen Tools, anstatt nur Tutorials anzuschauen.

4. Die 5 API-Schwachstellen, die Sie am haeufigsten sehen werden

Es gibt viele Arten von API-Schwachstellen, aber einige tauchen immer wieder auf. Dies sind diejenigen, die jeder Anfaenger zuerst lernen sollte.

4.1 Broken Object Level Authorization (BOLA/IDOR)

BOLA tritt auf, wenn eine API Ihnen den Zugriff auf ein Objekt erlaubt, das Ihnen nicht gehoert. Ein Objekt kann ein Profil, eine Bestellung, eine Rechnung, ein Ticket, eine Datei, eine Nachricht oder eine Zahlungsmethode sein.

Stellen Sie sich vor, Sie oeffnen Ihre Bestelldetails. Die API-Anfrage sieht aus wie /api/v1/orders/8842. Der Server prueft Ihr Token und gibt die Bestellung zurueck. Jetzt aendern Sie 8842 zu 8843, und der Server gibt die Bestellung einer anderen Person zurueck. Das ist BOLA.

Der Fehler ist einfach: Die API hat geprueft, dass Sie eingeloggt waren, aber sie hat nicht geprueft, ob Bestellung 8843 zu Ihrem Konto gehoerte. BOLA haelt die Spitzenposition der OWASP API Security Top 10, seit die Liste erstmals veroeffentlicht wurde.

So testen Sie auf BOLA:

• Suchen Sie nach jeder Anfrage, die eine ID enthaelt (Benutzer-ID, Bestell-ID, Rechnungs-ID, Ticket-ID, UUID, GUID)
• Aendern Sie die ID und beobachten Sie die Antwort
• Verwenden Sie zwei Konten und testen Sie, ob Konto A auf die Daten von Konto B zugreifen kann
• Pruefen Sie sowohl numerische sequenzielle IDs als auch UUIDs

4.2 Broken Authentication

Broken Authentication bedeutet, dass das System eine Schwachstelle in der Benutzerverifizierung oder Sitzungsverwaltung hat. Bei API-Tests betrifft dies typischerweise Tokens, Passwort-Zuruecksetzungs-Ablaeufe, Logout-Verhalten und OTP-Systeme.

Haeufige Probleme zum Testen:

• Refresh-Tokens, die nie ablaufen. Ein Access-Token kann nach 15 Minuten ablaufen, aber wenn das Refresh-Token nie ablaeuft, bedeutet ein gestohlenes Refresh-Token permanenten Zugriff
• Nur clientseitiges Logout. Die App entfernt das Token aus dem Speicher, aber der Server akzeptiert es weiterhin. Ein ordnungsgemaesses Logout muss die Sitzung serverseitig ungueltig machen
• Wiederverwendbare Passwort-Zuruecksetzungs-Tokens. Ein Reset-Token sollte zufaellig sein, schnell ablaufen und nur einmal funktionieren. Wenn es wiederverwendet oder erraten werden kann, eskaliert die Auswirkung zu einer Kontouebernahme
• Keine Ratenbegrenzung bei OTP. Wenn die API unbegrenzte OTP-Versuche ohne Zwei-Faktor-Authentifizierung-Schutzmaßnahmen erlaubt, kann ein Angreifer den Code per Brute Force knacken oder Credential Stuffing verwenden, um ihn zu umgehen

4.3 Broken Object Property Level Authorization

Diese Kategorie umfasst zwei verwandte Probleme: Excessive Data Exposure und Mass Assignment.

Excessive Data Exposure tritt auf, wenn die API mehr Informationen zurueckgibt, als das Frontend benoetigt. Entwickler senden manchmal vollstaendige Datenbankobjekte an den Client und vertrauen darauf, dass das Frontend nur die sicheren Felder anzeigt.

Zum Beispiel zeigt eine Bewertungsseite moeglicherweise nur den Namen des Bewerters und den Kommentar an. Aber die API-Antwort kann auch die E-Mail-Adresse des Bewerters, Telefonnummer, interne Benutzer-ID und Abteilungscode enthalten. Die Website verbirgt diese Felder, aber jeder, der die Antwort abfaengt, sieht sie.

Mass Assignment tritt auf, wenn die API mehr Felder vom Benutzer akzeptiert, als sie sollte. Entwickler binden manchmal den vollstaendigen Request-Body an das Datenbankobjekt und vergessen, sensible Felder zu blockieren.

Zum Beispiel erlaubt eine Profilaktualisierungsseite moeglicherweise nur die Aenderung von Name und Telefonnummer. Aber wenn die API auch role, isAdmin, isVerified oder accountBalance akzeptiert, kann der Benutzer Werte aendern, die er niemals kontrollieren sollte.

So testen Sie:

• Fuer Datenexposition: Inspizieren Sie jede rohe JSON-Antwort in Burp Suite. Suchen Sie nach Feldern wie email, phone, isAdmin, token, role, internalId
• Fuer Mass Assignment: Fuegen Sie zusaetzliche Felder zu Request-Bodies hinzu. Versuchen Sie "role": "admin", "isVerified": true, "plan": "enterprise" und pruefen Sie, ob die API sie akzeptiert

4.4 Broken Function Level Authorization

Dies tritt auf, wenn ein Benutzer eine Aktion ausfuehren kann, die nur einer anderen Rolle vorbehalten sein sollte. Im Gegensatz zu BOLA (Zugriff auf Daten eines anderen Benutzers) geht es hier darum, eine Funktion auszufuehren, die Ihre Rolle nicht haben sollte.

Ein normaler Benutzer sollte keine Admin-Endpunkte aufrufen koennen, die Benutzer erstellen, Konten loeschen, Zahlungen genehmigen oder Unternehmensdaten exportieren. Dies ist im Wesentlichen eine Form der Rechteausweitung. Selbst wenn der Admin-Button in der Benutzeroberflaeche ausgeblendet ist, benoetigt der API-Endpunkt dennoch serverseitige Berechtigungspruefungen.

Testansatz:

• Erfassen Sie alle Endpunkte und verstehen Sie, welche Aktionen zu welcher Rolle gehoeren
• Fangen Sie eine Anfrage eines hoeher privilegierten Kontos ab und wiederholen Sie sie mit einem niedriger privilegierten Token
• Suchen Sie nach Anfragefeldern wie role, isAdmin, type, privilege, accessLevel
• Der Server sollte niemals der vom Client gesendeten Rolle vertrauen

4.5 Unrestricted Resource Consumption

Dies tritt auf, wenn eine API Benutzern erlaubt, uebermaeßige Ressourcen zu verbrauchen: Speicher, CPU, Festplattenspeicher, Bandbreite oder Kosten fuer Drittanbieter-Dienste.

Zum Beispiel gibt eine Produkt-API normalerweise 20 Ergebnisse pro Seite mit limit=20 zurueck. Wenn Sie es zu limit=999999 aendern und der Server versucht, alles zurueckzugeben, kann die API langsamer werden oder abstuerzen. Ein PDF-Generierungs-Endpunkt, der pageCount=99999 akzeptiert, kann den gesamten verfuegbaren Speicher verbrauchen.

Zu testende Parameter: limit, pageSize, batchSize, count, quantity, width, height, duration, fileSize, pageCount.

Warnung: Viele Bug-Bounty-Programme erlauben keine Denial-of-Service-Tests. Bleiben Sie immer innerhalb des Scope und testen Sie vorsichtig.

5. Die OWASP API Top 10 erklaert

Die OWASP API Security Top 10 sind die branchenweite Standardliste der API-Sicherheitsrisiken. Das Update von 2023 hat mehrere Kategorien neu organisiert:

Fuer Anfaenger: Konzentrieren Sie sich zuerst auf diese:

1. API1 - Broken Object Level Authorization
2. API2 - Broken Authentication
3. API3 - Broken Object Property Level Authorization
4. API4 - Unrestricted Resource Consumption
5. API5 - Broken Function Level Authorization

Die verbleibenden fuenf Kategorien verdienen Aufmerksamkeit, wenn Ihre API-Hacking-Faehigkeiten wachsen:

• API6 - Unrestricted Access to Sensitive Business Flows: automatisierter Missbrauch von Geschaeftslogik (Ticket-Scalping, Massenerstellung von Konten)
• API7 - Server-Side Request Forgery (SSRF): den Server zwingen, Anfragen an interne Dienste ueber vom Benutzer bereitgestellte URLs zu senden
• API8 - Security Misconfiguration: permissive CORS-Richtlinien, ausfuehrliche Fehlermeldungen, fehlendes TLS, exponierte Debug-Endpunkte
• API9 - Improper Inventory Management: Shadow-APIs, alte ungepatchte Versionen (testen Sie immer /api/v1/, wenn /api/v2/ existiert) und exponierte Swagger-Dokumentation
• API10 - Unsafe Consumption of Third-Party APIs: Vertrauen in externe API-Antworten ohne Validierung

Anfaenger sollten zuerst in API1 bis API5 stark werden. Sobald Sie Zugriffskontrolle, Authentifizierung, Datenexposition und Ressourcenlimits durch praktische Uebung verstehen, bilden sich die restlichen Punkte der Liste natuerlich auf Bugs ab, die Sie bereits getestet haben.

6. So richten Sie Ihr erstes API-Testlabor ein

Testen Sie niemals zufaellige Websites ohne Genehmigung. Unbefugtes Testen kann gegen Gesetze wie den Computer Fraud and Abuse Act (CFAA) in den Vereinigten Staaten, den Computer Misuse Act im Vereinigten Koenigreich oder gleichwertige Gesetze in Ihrer Rechtsordnung verstossen. Verwenden Sie zuerst absichtlich verwundbare Labore, damit Sie ohne rechtliches Risiko lernen koennen. Fuer eine vollstaendige Umgebungsanleitung lesen Sie unseren Leitfaden zur Einrichtung eines Cybersecurity-Heimlabors.

Schritt-fuer-Schritt-Einrichtung:

1. Installieren Sie Burp Suite Community Edition. Richten Sie den Browser-Proxy ein, installieren Sie das Burp-CA-Zertifikat und bestaetigen Sie, dass Sie HTTPS-Verkehr erfassen koennen. Die Web Security Academy von PortSwigger hat eine kostenlose Anleitung.

2. Stellen Sie crAPI (Completely Ridiculous API) bereit. Dieses OWASP-Projekt wurde speziell fuer das Erlernen von API-Sicherheit entwickelt. Es enthaelt BOLA, Broken Authentication, Excessive Data Exposure und andere Schwachstellen, die auf die API Top 10 abgebildet sind. Dies ist der beste Ausgangspunkt.

3. Probieren Sie VAmPI. Eine einfache verwundbare REST-API zum Ueben von Authentifizierungs- und Autorisierungstests.

4. Wechseln Sie zu DVGA. Sobald Sie mit REST-APIs vertraut sind, lehrt dieses Labor GraphQL-spezifische Probleme wie Introspection-Missbrauch, Query-Manipulation und fehlerhafte Autorisierung in Resolvern.

Die Uebungsmethode: Oeffnen Sie das Labor, nutzen Sie es normal und erfassen Sie den Datenverkehr in Burp Suite. Senden Sie Anfragen an den Repeater. Aendern Sie IDs. Entfernen Sie Tokens. Aendern Sie Rollen. Modifizieren Sie Request-Bodies. Erhoehen Sie Limits. Wiederholen Sie alte Tokens. Lesen Sie jede Antwort.

Machen Sie sich Notizen waehrend des Uebens. Schreiben Sie den Endpunkt auf, was Sie geaendert haben, was der Server zurueckgegeben hat und warum das Verhalten falsch ist. Diese Gewohnheit uebertraegt sich direkt auf das Schreiben echter Bug-Reports und den Aufbau Ihres Sicherheitsportfolios.

7. Die 8 wesentlichen API-Sicherheitstest-Tools

Sie brauchen keine hundert Tools. Am Anfang sollten Sie wenige Tools tiefgehend verstehen.

1. Burp Suite - Ihr primaeres Tool. Fangen Sie Anfragen ab, modifizieren, wiederholen und vergleichen Sie sie. Der Repeater ist entscheidend fuer das Testen einer Anfrage mit kleinen Aenderungen.

2. Postman - Erstellen Sie API-Anfragen manuell und organisieren Sie sie in Sammlungen. Nuetzlich, wenn Sie den Endpunkt kennen und einen strukturierten Workflow wuenschen.

3. jwt.io - Dekodieren Sie JWT-Tokens, um Claims wie Benutzer-ID, Rolle, Ablaufzeit und Aussteller zu sehen. Hackt nichts, hilft aber zu verstehen, welche Informationen das Token traegt.

4. ffuf - Schneller Web-Fuzzer zum Entdecken versteckter Pfade, Endpunkte, Parameter und Werte.

5. Gobuster - Tool zur Verzeichnis- und Dateierkennung. Ergaenzt ffuf fuer breiteres Scannen.

6. Kiterunner - API-Routen-Erkennung, die speziell fuer API-Pfade konzipiert ist. API-bewusster als generische Directory-Brute-Forcer.

7. gau / waybackurls - Sammeln Sie alte URLs aus Webarchiven, um historische API-Endpunkte wie /api/ oder /graphql zu finden.

8. Nmap - Entdecken Sie offene Ports und Dienste. Verwenden Sie es, um API-Dienste zu finden, die auf nicht standardmaessigen Ports laufen.

Fuer die Analyse von API-Datenverkehr auf Netzwerkebene ist Wireshark ebenfalls nuetzlich, insbesondere beim Debugging von TLS- und Transportschicht-Problemen.

Tools sparen Zeit, ersetzen aber nicht das Denken. Die meisten guten API-Bugs werden gefunden, weil der Tester die Logik versteht, nicht weil ein Tool ein Ergebnis ausgegeben hat.

8. So finden Sie API-Endpunkte

Bevor Sie Bugs finden, muessen Sie die API-Oberflaeche finden. Das bedeutet, so viele Endpunkte wie moeglich zu entdecken.

Nutzen Sie die Anwendung. Loggen Sie sich ein, aktualisieren Sie Ihr Profil, laden Sie eine Datei hoch, suchen Sie etwas, aendern Sie Einstellungen, erstellen Sie eine Bestellung, stornieren Sie sie, laden Sie einen Benutzer ein, sehen Sie sich Benachrichtigungen an. Jede Aktion kann eine API-Anfrage erzeugen.

Untersuchen Sie JavaScript-Dateien. Moderne Webanwendungen speichern API-Pfade in JavaScript. Suchen Sie nach Woertern wie api, v1, v2, graphql, auth, token, upload, admin, payment, settings, internal.

Pruefen Sie auf API-Dokumentation. Exponierte Swagger UI- oder OpenAPI-Dateien offenbaren Endpunkte, Parameter, Request-Bodies, Authentifizierungsanforderungen und Beispielantworten. Das Finden exponierter Dokumentation kann Stunden sparen.

Scannen Sie Subdomains. APIs befinden sich oft auf Subdomains wie api.example.com, mobile.example.com, dev.example.com oder staging.example.com. Aeltere oder Staging-APIs haben haeufig schwaechere Sicherheit.

Durchsuchen Sie Webarchive. Tools wie gau und waybackurls offenbaren alte Endpunkte, die noch auf dem Server existieren. GitHub-Suchen koennen API-Pfade, Dokumentation oder geleakte Schluessel in oeffentlichen Repositories aufdecken.

Das Ziel ist es, eine vollstaendige Karte zu erstellen, bevor Sie tiefgehend testen. Wenn Sie die Endpunkte nicht kennen, wissen Sie nicht, was Sie testen sollen.

Nun, da Sie verstehen, wonach Sie suchen, lassen Sie uns die Methodik aufbauen, um Ihren ersten echten Bug zu finden.

9. Von API-Sicherheitslaboren zu echten Bug-Bounty-Programmen

Sobald Sie sich mit Laboren wohlfuehlen, beginnen Sie mit dem Testen echter Programme. Ueberstuerzen Sie diesen Schritt nicht.

Vor dem Testen:

• Lesen Sie den Programmumfang. Stellen Sie sicher, dass API-Tests erlaubt sind
• Pruefen Sie, welche Domains und Apps im Scope sind
• Ueberpruefen Sie, ob automatisiertes Scannen oder DoS-Tests eingeschraenkt sind
• Verstehen Sie die Responsible-Disclosure-Erwartungen des Programms

Ihre Einstiegsmethodik:

1. Erfassen Sie den Datenverkehr und kartieren Sie alle API-Endpunkte
2. Verstehen Sie Benutzerrollen und Berechtigungen
3. Testen Sie den Zugriff auf Objektebene (BOLA/IDOR)
4. Inspizieren Sie alle API-Antworten auf uebermaeßige Datenexposition
5. Testen Sie das Authentifizierungsverhalten (Token-Ablauf, Logout, Passwort-Zuruecksetzung)
6. Pruefen Sie, ob normale Benutzer Admin-Funktionen aufrufen koennen
7. Dokumentieren Sie alles fortlaufend

Das Befolgen dieser API-Sicherheitscheckliste fuer jedes Ziel schafft Konsistenz. Ihr erster gueltiger Report wird Ihnen mehr beibringen als jeder Kurs. Ihre erste Ablehnung wird Ihnen ebenfalls etwas beibringen. Ablehnungen sind Teil von Bug Bounty: Manchmal ist das Problem nicht schwerwiegend genug, manchmal ist es bereits bekannt, manchmal sind Ihre Schritte nicht klar genug. Lesen Sie die Antwort, verbessern Sie Ihre Methodik und testen Sie weiter.

10. Uebungsressourcen und naechste Schritte

Praktische Uebung und das Lesen echter Reports sollten zusammengehen. Labore helfen Ihnen, den Bug zu verstehen. Echte Reports helfen Ihnen, Auswirkungen und Berichtsstil zu verstehen.

Labore und Kurse:

• PortSwigger Web Security Academy - Kostenloses, umfassendes Web-Sicherheitstraining mit API-fokussierten Modulen
• crAPI - OWASPs speziell entwickeltes API-Sicherheitslabor
• VAmPI - Verwundbare REST-API fuer Authentifizierungstests
• Kontra - Interaktive Schwachstellenerklaerungen
• APIsec University - Dedizierte API-Sicherheitskurse

Buecher:

• Hacking APIs von Corey Ball - Der definitive Praxisleitfaden fuer API-Penetrationstests
• Black Hat GraphQL von Nick Aleks und Dolev Farhi - Tiefgehende Analyse der GraphQL-Sicherheit

Lesen Sie veroeffentlichte Reports. Suchen Sie auf HackerOne und Bugcrowd nach Reports mit den Tags API, IDOR, BOLA, Broken Authentication und Excessive Data Exposure. Das Lesen einiger Reports pro Woche trainiert Ihre Mustererkennung.

Google-Dork-Beispiele zum Finden oeffentlicher Reports:

• site:hackerone.com/reports/* intext:API
• site:hackerone.com/reports/* intext:IDOR
• site:hackerone.com/reports/* intext:GraphQL

Ihr Lernpfad:

Wenn Sie bei Null anfangen, folgen Sie dieser Reihenfolge: Lernen Sie HTTP und JSON, dann Burp Suite. Ueben Sie mit crAPI. Verstehen Sie BOLA tiefgehend. Gehen Sie zu Broken Authentication, Excessive Data Exposure, Function-Level Authorization und Ressourcenlimits ueber. Lesen Sie echte Reports. Starten Sie Bug-Bounty-Programme. Validieren Sie Ihre Faehigkeiten mit Cybersecurity-Zertifizierungen fuer Anfaenger, um zu sehen, wo API-Sicherheitstests in die breitere Offensive-Security-Landschaft passen.

Ihr erster API-Bug kann vom Aendern einer einzelnen ID, dem Wiederholen eines einzelnen Tokens oder dem Bemerken eines versteckten Feldes in einer JSON-Antwort kommen. Bei API-Sicherheitstests geht es nicht darum, Payloads auswendig zu lernen. Es geht darum, Vertrauen zu verstehen und API-Security-Best-Practices auf jeder Ebene anzuwenden. Kann die API diesem Benutzer vertrauen? Kann sie dieser ID vertrauen? Kann sie diesem Rollenwert vertrauen? Die meisten API-Bugs entstehen, wenn der Server etwas vertraut, das er verifizieren sollte.

Genau deshalb sind API-Penetrationstests ein so wirkungsvoller Einstieg in Ihre Cybersecurity-Karriere.