API-Sicherheit: OWASP API Top 10, Authentifizierung, Testing und Best Practices

APIs sind das Rückgrat moderner Software - und der am schnellsten wachsende Angriffsvektor. Während klassische Web-Applikationen oft gut abgesichert sind, führen APIs häufig sensitive Operationen direkt aus, haben weniger UI-Sicherheitsmechanismen und werden selten gründlich getestet. Laut OWASP sind die meisten kritischen Web-Application-Sicherheitsvorfälle 2023/2024 über APIs erfolgt. Dieser Artikel behandelt die vollständige OWASP API Security Top 10, Authentifizierungsverfahren, Testmethodik und den richtigen Tool-Einsatz.

OWASP API Security Top 10 (2023)

API1: Broken Object Level Authorization (BOLA/IDOR)

Die häufigste und gefährlichste API-Schwachstelle: Der Angreifer ändert eine Ressourcen-ID in der URL und erhält Daten eines anderen Nutzers, weil die API nur prüft, ob jemand eingeloggt ist, nicht ob die Ressource ihm gehört.

Das verwundbare Muster in Node.js/Express liest die User-ID aus dem URL-Parameter und gibt Bestellungen zurück, ohne zu prüfen ob sie dem authentifizierten Nutzer gehören. Die sichere Variante liest die User-ID aus dem validierten JWT-Token statt aus der URL:

// Sicher: User aus Auth-Token, nicht aus URL
app.get('/api/v1/orders', auth, (req, res) => {
  // req.user.id kommt aus validiertem JWT
  const orders = db.query('SELECT * FROM orders WHERE user_id = ?', req.user.id);
  res.json(orders);
});

// Wenn URL-ID nötig: Ownership-Check!
app.get('/api/v1/orders/:orderId', auth, async (req, res) => {
  const order = await db.getOrder(req.params.orderId);
  if (!order || order.userId !== req.user.id) {
    return res.status(404).json({ error: 'Not found' });  // 404, nicht 403!
  }
  res.json(order);
});

Schutzprinzipien: Jeden API-Endpunkt auf Objekt-Eigentümerschaft prüfen, lieber 404 als 403 zurückgeben (verhindert Enumeration), UUIDs statt auto-increment IDs verwenden (kein Ersatz für Auth, aber reduziert Ratenangriffe) und eine zentrale Autorisierungsschicht statt verstreute Checks in jedem Endpoint implementieren.

API2: Broken Authentication

Häufige Probleme sind fehlendes Rate Limiting auf Login-Endpunkten (Brute Force), schwache JWT-Secrets, JWTs ohne Ablaufdatum, API-Keys in der URL statt im Header sowie der JWT Algorithm-None-Angriff.

// Sicheres JWT erstellen (Node.js)
const token = jwt.sign(
  { userId: user.id, email: user.email },
  process.env.JWT_SECRET,     // Aus Environment, nicht hardcoded!
  {
    expiresIn: '15m',         // Kurze Laufzeit für Access Token
    issuer: 'api.firma.de',
    audience: 'api.firma.de',
    algorithm: 'RS256'        // Asymmetrisch - besser als HS256!
  }
);

// Token validieren - Algorithmus explizit angeben!
const decoded = jwt.verify(token, process.env.JWT_PUBLIC_KEY, {
  issuer: 'api.firma.de',
  audience: 'api.firma.de',
  algorithms: ['RS256'],      // Verhindert Algorithm Confusion Attack (alg: "none")
});

API-Keys sollten als Hash in der Datenbank gespeichert werden (wie Passwörter), im HTTP-Header übertragen werden (X-API-Key: sk_live_abc123xyz), niemals in der URL erscheinen (landet in Server-Logs, Browser-History und Proxies), pro Service oder Consumer ausgestellt sein, ein Ablaufdatum haben und rotiert werden.

API3: Broken Object Property Level Authorization

Diese Kategorie aus OWASP 2023 fasst Mass Assignment und Excessive Data Exposure zusammen. Beim Mass Assignment kann ein Angreifer Felder wie role oder balance im Request-Body mitschicken, die eigentlich nicht aktualisierbar sein sollten. Die sichere Lösung ist eine explizite Allowlist erlaubter Felder, etwa per Pydantic-Schema in FastAPI oder Zod-Schema in Node.js.

Excessive Data Exposure bedeutet, dass die API zu viele Felder zurückgibt - etwa password_hash, internal_id oder payment_token. Das Response-Model sollte explizit auf die nötigen Felder begrenzt werden.

API4: Unrestricted Resource Consumption

Fehlendes Rate Limiting ermöglicht DoS-Angriffe, erhöht Kosten und erlaubt Credential Stuffing.

# Rate Limiting (Python/FastAPI mit slowapi)
from slowapi import Limiter
from slowapi.util import get_remote_address

limiter = Limiter(key_func=get_remote_address)

@app.post("/api/auth/login")
@limiter.limit("5/minute;20/hour")  # Brute-Force-Schutz
async def login(request: Request, credentials: LoginRequest):
    ...

# Pagination erzwingen - max. 100 Einträge pro Request
@app.get("/api/users")
async def get_users(
    page: int = 1,
    limit: int = Query(default=20, le=100)
):
    offset = (page - 1) * limit
    return db.query(User).offset(offset).limit(limit).all()

Auch File-Uploads brauchen Limits: Erlaubte MIME-Types prüfen (image/jpeg, image/png, application/pdf) und eine maximale Dateigröße von beispielsweise 10 MB erzwingen.

API5: Broken Function Level Authorization

Vertikale Privilegieskalation: normale Nutzer können Admin-Endpunkte aufrufen. Die Lösung ist eine separate Admin-Middleware, die den Role-Check vor der eigentlichen Handler-Funktion ausführt. Admin-Endpunkte sollten außerdem ein komplett separates Prefix (/admin/* statt /api/*), eigene Authentifizierung, keine gemeinsamen JWTs mit regulären Nutzern und eine IP-Allowlist für das Büronetz oder VPN haben.

API6-10: Weitere kritische Risiken

API6 - Unrestricted Access to Sensitive Business Flows: Automatisierbarer Missbrauch von Geschäftsprozessen. Schutz durch Rate Limiting für Business-Logik (Bestellungen, Coupons, Gift-Cards), CAPTCHAs für öffentliche Formulare und Velocity Checking.

API7 - Server Side Request Forgery (SSRF): URL-Parameter wie webhook=, callback=, url= oder src= können interne Ressourcen ansprechen. Besonders kritisch: der AWS Metadata-Endpoint 169.254.169.254 liefert IAM-Credentials. Schutz durch Blocklisting privater IP-Ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16) und Routing aller ausgehenden HTTP-Anfragen durch einen Proxy mit IP-Check. DNS-Rebinding beachten: die IP kann sich nach der DNS-Auflösung ändern.

API8 - Security Misconfiguration: Zu weite CORS-Konfiguration (Access-Control-Allow-Origin: * für interne APIs), Fehlerdetails in der Produktion (Stack-Traces, SQL-Fehler), aktiver Debug-Modus und Default-Credentials. CORS richtig konfigurieren bedeutet, explizit nur die erlaubten Origins zu nennen; ein globaler Exception-Handler sollte in Produktion ausschließlich generische Fehlermeldungen zurückgeben.

API9 - Improper Inventory Management: Undokumentierte Legacy-Endpoints (v1 noch aktiv obwohl v3 current), Sandbox-Umgebungen mit echten Daten und Shadow-APIs ohne Owner. Schutz durch OpenAPI/Swagger für alle Endpoints, API-Gateway als Single Entry Point und eine klare Versionierungs-Policy (v1 deprecated und deaktiviert).

API10 - Unsafe Consumption of APIs: Blindes Vertrauen in externe API-Responses. Externe Responses immer mit Pydantic oder Zod validieren, Timeouts auf maximal 10 Sekunden setzen und Circuit Breaker für Cascade-Failure-Schutz implementieren.

API-Authentifizierung - Vergleich

API Keys eignen sich für Server-to-Server-Kommunikation und Entwickler-APIs. Sie bieten mittlere Sicherheit, da sie kein Ablaufdatum haben und oft breite Rechte gewähren. Best Practices: Header statt URL, pro Service eigener Key, regelmäßige Rotation, Audit-Log und Hash-Speicherung in der Datenbank.

JWT (JSON Web Token) ist geeignet für Web- und Mobile-Apps mit stateless Authentication und bietet hohe Sicherheit bei korrekter Implementierung. Zu beachten: Algorithm-None-Angriff durch explizite Algorithmus-Whitelist verhindern, Secret in Umgebungsvariablen (nie hardcoded), kurze Gültigkeitsdauer (15 Minuten für Access, 7 Tage für Refresh), kein sensitiver Inhalt im Payload (Base64, nicht verschlüsselt) und jti-Claim für Token-Revocation.

OAuth 2.0 + OpenID Connect ist der Industriestandard für Third-Party-Authentication und Delegation. Authorization Code + PKCE für Web- und Mobile-Apps, Client Credentials für Server-to-Server, state-Parameter auf CSRF prüfen. Der Implicit Flow ist veraltet und unsicher und sollte nie verwendet werden.

mTLS (Mutual TLS) bietet maximale Sicherheit für Microservices und B2B-APIs, da sich beide Seiten mit Zertifikat authentifizieren. Es gibt keinen Bearer Token der gestohlen werden kann. Der Setup ist komplexer, aber die Sicherheit ist maximal.

GraphQL-Sicherheit

GraphQL bringt eigene Sicherheitsherausforderungen:

// 1. Introspection in Produktion deaktivieren
const server = new ApolloServer({
  typeDefs, resolvers,
  introspection: process.env.NODE_ENV !== 'production',
});

// 2. Query Depth Limit (DoS-Schutz gegen verschachtelte Queries)
import depthLimit from 'graphql-depth-limit';
const server = new ApolloServer({
  validationRules: [depthLimit(5)],  // Max 5 Ebenen
});

// 3. Batching-Limit (verhindert Rate-Limit-Bypass via Batch-Requests)
const server = new ApolloServer({
  allowBatchedHttpRequests: false,
});

Eine ungeschützte verschachtelte Query wie { user { friends { friends { friends { name } } } } } kann exponentiell teuer werden und einen DoS verursachen. Ebenso erlaubt GraphQL mehrere Queries in einem Request - ohne Batching-Limit können 100 Login-Versuche in einem einzigen HTTP-Request versteckt werden, was Rate-Limiting umgeht.

Autorisierung gehört in die Resolver-Funktion, nicht ins Schema. Field-Level-Authorization muss explizit geprüft werden: Felder wie internalNotes oder passwordHash dürfen nie zurückgegeben werden, auch wenn sie im Schema existieren.

API-Discovery und Reconnaissance

Zur Identifikation von API-Endpunkten in der Testphase können passive und aktive Quellen kombiniert werden.

Passive Quellen: Swagger/OpenAPI-Dokumentation (/swagger.json, /openapi.yaml, /api-docs), Analyse des JavaScript-Bundles über Chrome DevTools Network-Tab (XHR/Fetch-Filter), öffentliche GitHub-Repositories, dekompilierte Mobile-Apps (APK/IPA), öffentliche Postman-Sammlungen (oft mit API-Keys in Requests!) und die Wayback Machine für alte API-Versionen.

# Directory Brute-Force mit API-Wordlist
feroxbuster -u https://api.target.com \
  -w /usr/share/wordlists/SecLists/Discovery/Web-Content/api/api-endpoints.txt \
  -x json \
  -H "Accept: application/json"

# kiterunner (API-spezifisch)
kr scan https://api.target.com -w routes-large.kite

Swagger-UI, das in der Produktion erreichbar ist, gibt ohne Authentifizierung die vollständige API-Dokumentation preis. GraphQL-Introspection liefert das komplette Schema.

Testing-Methodik für die OWASP API Top 10

BOLA/IDOR (API1): Zwei Testkonten erstellen, mit dem Token von Nutzer B auf Ressourcen von Nutzer A zugreifen, IDs iterieren (auch UUIDs sind getestet). Burp Intruder eignet sich für systematisches ID-Bruteforcing.

Authentication (API2): JWT-Schwächen testen: alg=none-Angriff, RS256-zu-HS256-Key-Confusion, abgelaufene Tokens auf Akzeptanz prüfen. Tool: jwt_tool TOKEN -T für Tamper-Mode, jwt_tool TOKEN -C -d rockyou.txt für HMAC-Secret-Cracking. API-Key in der URL prüfen, Rate-Limiting auf Login-Endpunkten testen.

Mass Assignment (API3): Antwort des GET-Endpunkts auf interne Felder prüfen (isAdmin, creditScore). Beim PUT interne Felder wie role: "admin" mitsenden und prüfen ob sie übernommen werden.

Rate Limiting (API4): 1000 Login-Requests ohne Lockout absenden. OTP/Reset-Tokens auf Brute-Force-Möglichkeit testen. Rate-Limit-Bypass-Vektoren prüfen: X-Forwarded-For-Header rotieren, verschiedene API-Versionen testen (separate Rate-Limits möglich).

SSRF (API7): Alle URL-Parameter (webhook=, callback=, url=, redirect=, src=) auf SSRF testen, besonders gegen http://169.254.169.254/latest/meta-data/ (AWS Metadata).

Security Misconfiguration (API8): CORS-Test mit Origin: https://evil.com Header, ungewollte HTTP-Methoden (OPTIONS, TRACE, PUT) prüfen, Debug-Endpoints und Stack-Traces in 500-Errors suchen.

Tooling-Stack für API-Pentests

Burp Suite Pro ist das zentrale Werkzeug: HTTP-Proxy für alle API-Requests, Intruder für BOLA-Tests und Brute-Force, automatischer Scanner, Extensions für GraphQL (InQL), JWT (JWT Editor) und Autorisierungstests (AuthMatrix).

Postman eignet sich für Dokumentationsimport (OpenAPI), Token-Rotation via Pre-Request Scripts und automatische Response-Validierung.

Weitere Tools: jwt_tool für JWT-Tests, kiterunner für API-Endpoint-Discovery, Nuclei mit API/JWT/Swagger-Templates für automatische Scans, OWASP ZAP für CI/CD-integrierte DAST-Scans.

Für kontinuierliche API Security in CI/CD bietet sich 42Crunch API Security Audit als GitHub Action an, die OpenAPI-Specs auf Sicherheit bewertet und bei einem Score unter 75 fehlschlägt.

API-Sicherheitstest-Checkliste

Authentifizierung:

• Ist jeder Endpunkt authentifiziert? (kein versehentlicher öffentlicher Endpoint)
• Brute Force Rate Limiting auf Auth-Endpoints?
• JWT: kurze Laufzeit, sicherer Algorithmus (RS256), kein "alg: none"?
• Tokens nach Logout invalidiert?
• API-Keys in HTTP-Header, nicht in URL?

Autorisierung:

• BOLA-Test: andere User-IDs in URL/Body testen
• Admin-Endpunkte: ohne Admin-Rechte aufrufbar?
• Mass Assignment: werden unerwartete Felder ignoriert?
• Scope-Check: OAuth Scopes korrekt geprüft?
• HTTP-Methoden-Beschränkung: GET vs. DELETE vs. PUT?

Input Validation:

• SQL Injection auf alle Parameter?
• NoSQL Injection (MongoDB: $where, $gt Operator)?
• Schema-Validierung für alle Request Bodies?
• Datei-Upload: Typ-Check, Größen-Limit, Malware-Scan?

Rate Limiting:

• Rate Limiting auf allen Endpunkten?
• Pro-User statt nur per-IP?
• Business-Logic-Rate-Limiting (Coupons, Bestellungen)?
• Rate-Limit-Bypass-Vektoren getestet?

Security Misconfiguration:

• CORS korrekt konfiguriert (kein * wenn Credentials genutzt)?
• HTTP Security Headers gesetzt?
• Fehlerdetails in Antwort ausgeblendet (kein Stack-Trace)?
• Alte API-Versionen deaktiviert?
• Swagger/OpenAPI Docs in Produktion deaktiviert oder auth-geschützt?
• Debug-Endpoints deaktiviert?

OWASP API Top 10 Gesamtcheck:

• API1: BOLA getestet (zwei Accounts, ID-Iteration)
• API2: Auth-Bypass versucht (JWT alg:none, Key-Confusion)
• API3: Mass Assignment getestet, Response-Felder geprüft
• API4: Rate Limiting vorhanden und nicht bypassbar
• API5: Privilegierte Endpoints geprüft
• API6: Business-Logic-Flows auf Automation getestet
• API7: SSRF getestet (alle URL-Parameter)
• API8: CORS, Security Headers, Debug deaktiviert
• API9: API-Inventar vollständig, alte Versionen deaktiviert
• API10: Third-Party-Responses validiert, Timeouts gesetzt