API-Sicherheitstests: OWASP Top 10, Tools und Checkliste

Einleitung

APIs sind der häufigste Angriffsvektor in modernen Anwendungen. Laut Gartner waren API-Angriffe bis 2024 der häufigste Angriffsvektor für Enterprise-Webanwendungen. Jede API, die Sie exponieren, ist ein potenzieller Einstiegspunkt für Angreifer, und herkömmliche Sicherheitstests für Webanwendungen reichen nicht aus, um sie zu schützen.

API-Sicherheitstests sind die Praxis, Ihre API-Endpunkte systematisch auf Schwachstellen, Authentifizierungsumgehungen, Datenoffenlegungen, Injection-Angriffe und Geschäftslogik-Fehler zu testen. Dieser Leitfaden behandelt die OWASP API Security Top 10, praktische Testtechniken mit Codebeispielen, die besten verfügbaren Tools und eine umfassende Checkliste.

Ob Sie Entwickler, QA-Ingenieur oder DevSecOps-Verantwortlicher sind: Dieser Leitfaden liefert Ihnen umsetzbare Techniken zur Absicherung Ihrer APIs.

OWASP API Security Top 10 (2023)

Die OWASP API Security Top 10 ist das Industriestandard-Framework für API-Sicherheitsrisiken. Hier sind die einzelnen Schwachstellen mit Testtechniken:

API1: Broken Object Level Authorization (BOLA)

Die häufigste API-Schwachstelle. Ein Angreifer manipuliert Objekt-IDs in Anfragen, um auf Daten anderer Nutzer zuzugreifen.

Testmethode:

# Log in as User A, get their resource
curl -X GET https://api.example.com/users/101/orders \
  -H "Authorization: Bearer USER_A_TOKEN"
# Returns User A's orders ✓
# Now try accessing User B's resource with User A's token
curl -X GET https://api.example.com/users/102/orders 

-H "Authorization: Bearer USER_A_TOKEN"
# Should return 403 Forbidden, not User B's orders

Lösung: Stellen Sie stets sicher, dass der authentifizierte Nutzer die angeforderte Ressource besitzt (oder Zugriffsrechte dafür hat). Verlassen Sie sich niemals allein auf vom Client gelieferte IDs.

API2: Broken Authentication

Schwache Authentifizierungsmechanismen, die es Angreifern ermöglichen, Token, Schlüssel oder Passwörter zu kompromittieren.

Was zu testen ist:

• Können Sie auf geschützte Endpunkte ohne Token zugreifen? (Erwartung: 401)
• Akzeptiert die API abgelaufene Token?
• Gibt es Rate Limiting bei Login-Versuchen?
• Werden Token bei Logout oder Passwortänderung invalidiert?
• Wird der Token sicher gespeichert (HttpOnly-Cookies, nicht localStorage)?

# Test: No auth header
curl -X GET https://api.example.com/users/me
# Expected: 401 Unauthorized
# Test: Expired token
curl -X GET https://api.example.com/users/me 

-H "Authorization: Bearer EXPIRED_TOKEN_HERE"
# Expected: 401 Unauthorized
# Test: Brute force protection (rapid login attempts)
for i in {1..100}; do
curl -s -o /dev/null -w "%{http_code}\n" 

-X POST https://api.example.com/auth/login 

-d '{"email":"victim@example.com","password":"guess'$i'"}'
done
# Expected: 429 Too Many Requests after several attempts

API3: Broken Object Property Level Authorization

Die API gibt sensible Objekteigenschaften preis, die verborgen oder schreibgeschützt sein sollten.

Testmethode:

# Test: Can a regular user set admin-only fields?
curl -X PATCH https://api.example.com/users/101 \
  -H "Authorization: Bearer REGULAR_USER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"role": "admin", "isVerified": true}'
# Expected: "role" and "isVerified" should be ignored or return 403

API4: Unrestricted Resource Consumption

Die API begrenzt keine Anfragerate, Payload-Größen oder ressourcenintensive Operationen.

Was zu testen ist:

• Überdimensionierte Payloads senden (100 MB JSON-Body)
• Sehr große Seitengröße anfordern (GET /users?limit=1000000)
• Kostspielige Operationen wiederholt auslösen
• Exzessiv große Dateien hochladen

API5: Broken Function Level Authorization

Reguläre Nutzer können auf Admin-only-API-Endpunkte zugreifen.

# Test: Access admin endpoints with regular user token
curl -X GET https://api.example.com/admin/users \
  -H "Authorization: Bearer REGULAR_USER_TOKEN"
# Expected: 403 Forbidden
curl -X DELETE https://api.example.com/admin/users/102 

-H "Authorization: Bearer REGULAR_USER_TOKEN"
# Expected: 403 Forbidden

API6: Unrestricted Access to Sensitive Business Flows

Automatisierter Missbrauch legitimer Geschäftsfunktionen: Scalping, Spam, Coupon-Missbrauch.

API7: Server Side Request Forgery (SSRF)

Die API ruft externe URLs ab, die vom Nutzer ohne Validierung angegeben wurden, und ermöglicht Angreifern so das Scannen interner Netzwerke.

# Test: Try to access internal services via URL parameter
curl -X POST https://api.example.com/fetch-url \
  -d '{"url": "http://169.254.169.254/latest/meta-data/"}'
# Should be blocked, this targets AWS metadata
curl -X POST https://api.example.com/fetch-url 

-d '{"url": "http://localhost:6379/"}'
# Should be blocked, this targets internal Redis

API8: Security Misconfiguration

Fehlende Sicherheits-Header, ausführliche Fehlermeldungen, unnötig aktivierte HTTP-Methoden.

# Test: Check security headers
curl -I https://api.example.com/users
# Verify these headers are present:
# X-Content-Type-Options: nosniff
# X-Frame-Options: DENY
# Strict-Transport-Security: max-age=31536000
# Content-Security-Policy: default-src 'self'
# Test: Check for verbose error messages
curl -X GET https://api.example.com/users/invalid
# Should NOT expose stack traces, database details, or internal paths

API9: Improper Inventory Management

Alte API-Versionen noch zugänglich, undokumentierte Endpunkte exponiert, Entwicklungs- und Staging-Endpunkte öffentlich erreichbar.

Was zu testen ist: Versuchen Sie, auf /api/v1/ zuzugreifen, wenn /api/v2/ aktuell ist. Prüfen Sie häufige Pfade wie /debug, /swagger, /graphql, /actuator.

API10: Unsafe Consumption of APIs

Die API vertraut Daten von Drittanbieter-APIs blindlings ohne Validierung.

Tools für API-Sicherheitstests

OWASP ZAP (Zed Attack Proxy)

Kostenloses, quelloffenes Sicherheitstesttool, das von OWASP gepflegt wird. Es kann APIs automatisch auf häufige Schwachstellen scannen.

# Run ZAP against your API using the API scan
docker run -t zaproxy/zap-stable zap-api-scan.py \
  -t https://api.example.com/openapi.json \
  -f openapi \
  -r report.html

Burp Suite

Das Industriestandard-Tool für Web- und API-Sicherheitstests. Burp Suite Professional bietet automatisches Scanning, Intruder (Fuzzing) und Repeater für manuelle Tests.

Postman und Sicherheitsskripte

Sie können Ihren bestehenden Postman-Collections Sicherheitstestskripte hinzufügen:

// Postman test script for security checks
pm.test("No sensitive data in response", () => {
  const body = pm.response.text();
  pm.expect(body).to.not.include("password");
  pm.expect(body).to.not.include("ssn");
  pm.expect(body).to.not.include("credit_card");
});
pm.test("Security headers present", () => {
pm.expect(pm.response.headers.get("X-Content-Type-Options")).to.equal("nosniff");
pm.expect(pm.response.headers.get("Strict-Transport-Security")).to.exist;
});
pm.test("No server version disclosure", () => {
pm.expect(pm.response.headers.get("Server")).to.not.include("Apache/2.4");
pm.expect(pm.response.headers.get("X-Powered-By")).to.not.exist;
});

Qodex.ai

Qodex.ai enthält integrierte Sicherheitstests, die Ihre APIs automatisch auf OWASP Top 10-Schwachstellen scannen. Der KI-Agent generiert Sicherheitstestfälle parallel zu funktionalen Tests und deckt Authentifizierungsumgehungen, Injection-Angriffe und Datenoffenlegungen ab, ohne dass Sicherheitsexpertise erforderlich ist.

Nuclei

Schneller, vorlagenbasierter Schwachstellen-Scanner. Tausende von Community-Vorlagen für API-Sicherheitstests.

# Scan an API for known vulnerabilities
nuclei -u https://api.example.com -t api/ -severity critical,high

Tool-Vergleich

Checkliste für API-Sicherheitstests

Verwenden Sie diese Checkliste für jede API, die Sie entwickeln oder prüfen:

Authentifizierung

• Alle Endpunkte erfordern Authentifizierung (außer öffentlichen)
• Token laufen innerhalb eines angemessenen Zeitrahmens ab
• Refresh-Token-Rotation ist implementiert
• Fehlgeschlagene Login-Versuche werden per Rate Limiting begrenzt
• Passwort-Reset-Flows sind sicher
• API-Keys werden nicht in URLs exponiert (Header verwenden)

Autorisierung

• Autorisierung auf Objektebene bei jedem Endpunkt (BOLA-Schutz)
• Autorisierung auf Funktionsebene (Admin-Endpunkte beschränkt)
• Autorisierung auf Eigenschaftsebene (sensible Felder geschützt)
• Autorisierung kann nicht durch Ändern der HTTP-Methode umgangen werden

Eingabevalidierung

• Alle Eingaben werden validiert (Typ, Länge, Format, Bereich)
• SQL-Injection-Schutz (parametrisierte Abfragen)
• NoSQL-Injection-Schutz
• Größenlimits für Request-Bodies werden durchgesetzt
• Datei-Upload-Validierung (Typ, Größe, Inhalt)

Datenschutz

• HTTPS wird durchgesetzt (HSTS-Header vorhanden)
• Sensible Daten nicht in Antworten exponiert (Passwörter, Token, personenbezogene Daten)
• Sensible Daten werden nicht protokolliert
• CORS restriktiv konfiguriert
• Antwort-Header verhindern Caching sensibler Daten

Rate Limiting und Drosselung

• Rate Limits an allen Endpunkten
• Strengere Limits an Authentifizierungsendpunkten
• Rate-Limit-Header werden zurückgegeben (X-RateLimit-*)
• HTTP-Statuscode 429 wird zurückgegeben, wenn Limits überschritten werden

Sicherheitstests in CI/CD integrieren

Sicherheitstests sollten automatisiert und bei jeder Code-Änderung ausgeführt werden, nicht nur vor Releases.

# GitHub Actions, API security scan
name: API Security Tests
on:
  push:
    branches: [main, develop]
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
  - name: Start API server
    run: docker-compose up -d

  - name: Wait for API
    run: npx wait-on http://localhost:3000/health

  - name: Run OWASP ZAP scan
    uses: zaproxy/action-api-scan@v0.7.0
    with:
      target: http://localhost:3000/openapi.json
      rules_file_name: .zap/rules.tsv
      fail_action: true

  - name: Run custom security tests
    run: npm run test:security

  - name: Upload security report
    if: always()
    uses: actions/upload-artifact@v4
    with:
      name: security-report
      path: zap-report.html

Verwandt: How to Get a Rugcheck API Key and Start Using the API

Eine sicherheitsorientierte API-Teststrategie aufbauen

API-Sicherheitstests funktionieren am besten in Kombination mit anderen Testarten:

• Funktionstests, korrektes Verhalten sicherstellen (REST-API-Testleitfaden)
• Lasttests, Performance unter Druck prüfen (API-Lasttests)
• Integrationstests, Service-Interaktionen prüfen (API-Integrationstests)
• Sicherheitstests, Schutz gegen Angriffe sicherstellen (dieser Leitfaden)

Für einen umfassenden Überblick aller verfügbaren Test-Tools siehe unseren API-Testing-Tools-Vergleich.

Häufig gestellte Fragen

Was sind API-Sicherheitstests?

API-Sicherheitstests sind der Prozess, API-Endpunkte auf Schwachstellen, Authentifizierungsumgehungen, Injection-Angriffe, Datenoffenlegungen und Autorisierungsfehler zu testen. Ziel ist es, Sicherheitslücken zu identifizieren und zu beheben, bevor Angreifer sie ausnutzen.

Was sind die OWASP API Security Top 10?

Die OWASP API Security Top 10 ist eine Liste der kritischsten API-Sicherheitsrisiken, gepflegt vom Open Worldwide Application Security Project. Sie umfasst Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization und sieben weitere häufige API-Schwachstellen.

Wie starte ich mit API-Sicherheitstests?

Beginnen Sie mit der obigen OWASP API Security Top 10-Checkliste. Führen Sie einen automatisierten Scan mit OWASP ZAP gegen Ihre API-Spezifikation durch. Testen Sie dann manuell Authentifizierung, Autorisierung und Injection-Schwachstellen. Nutzen Sie Qodex.ai, um automatisch Sicherheitstestfälle aus Ihrer API-Spezifikation zu generieren.

Welche Tools eignen sich am besten für API-Sicherheitstests?

OWASP ZAP (kostenlos, automatisiertes Scanning), Burp Suite (professionelle Penetrationstests), Qodex.ai (KI-gestützte Sicherheitstestgenerierung) und Nuclei (vorlagenbasiertes Scanning). Die meisten Teams kombinieren automatisierte und manuelle Testtools.

Was ist der Unterschied zwischen SAST und DAST für APIs?

SAST (Static Application Security Testing) analysiert Quellcode, ohne die Anwendung auszuführen. DAST (Dynamic Application Security Testing) testet die laufende API durch das Senden von Anfragen und die Analyse von Antworten. Beide sind wertvoll: SAST erkennt Code-Probleme frühzeitig, und DAST findet Laufzeitschwachstellen.

Wie oft sollte ich API-Sicherheitstests durchführen?

Automatisierte Sicherheitsscans sollten bei jedem Deployment (in CI/CD) ausgeführt werden. Umfassende Penetrationstests sollten vierteljährlich oder vor größeren Releases durchgeführt werden. Überwachen Sie kontinuierlich nach neuen Schwachstellen in Abhängigkeiten mit Tools wie Dependabot oder Snyk.