Home› Blog› API-Sicherheit: Wie Sie REST-APIs vor Angriffen schützen
Sicherheit

API-Sicherheit: Wie Sie REST-APIs vor Angriffen schützen

23. März 2026

Stellen Sie sich vor: Ein Angreifer findet eine einzige schlecht abgesicherte API-Schnittstelle in Ihrer Anwendung — und hat damit direkten Zugriff auf alle Kundendaten. Kein Passwort, keine Verschlüsselung, kein Firewall-System hilft, wenn die API selbst fehlerhaft implementiert ist. Laut dem Verizon Data Breach Investigation Report 2024 sind APIs an über 74 % aller Datenpannen beteiligt. Für deutsche Unternehmen kommt doppelter Druck durch die DSGVO hinzu: Ein Datenleck durch eine schlecht gesicherte API kann Bußgelder bis zu 4 % des weltweiten Jahresumsatzes bedeuten.

OWASP führt die API Security Top 10 als eigenständige Liste — getrennt von der klassischen Web-Security-Liste, weil API-Angriffe eigene Muster und Charakteristika haben. Dieser Leitfaden erklärt die kritischsten Bedrohungen, gibt Ihnen konkrete Implementierungsbeispiele und eine praxistaugliche Checkliste für den Produktiveinsatz.

Warum API-Sicherheit sich von Web-Security unterscheidet

Klassische Web-Security fokussiert sich auf HTML-Rendering, Cookie-Management und Browser-Interaktionen. APIs arbeiten fundamental anders: Sie liefern strukturierte Daten direkt — oft ohne Sicherheitsschicht zwischen Angriff und Datenbankzugriff. Ein Angreifer braucht keinen Browser. Ein einfaches curl-Kommando reicht aus.

Drei Eigenschaften machen APIs besonders angreifbar:

Die Konsequenz für Entwicklungsteams: API-Sicherheit muss von Anfang an als Designprinzip betrachtet werden, nicht als nachträgliche Schicht.

Die OWASP API Security Top 10: Die häufigsten Bedrohungen

Broken Object Level Authorization (BOLA)

BOLA ist der häufigste API-Angriff und gleichzeitig einer der einfachsten durchzuführen. Ein Nutzer ändert eine ID in einer API-Anfrage und greift auf Daten anderer Nutzer zu.

Beispiel: GET /api/orders/12345 gibt Bestelldetails zurück. Wenn der Server nicht prüft, ob die Bestellung zum eingeloggten Nutzer gehört, kann jeder mit einem gültigen Token jede Bestellung abrufen — durch einfaches Hochzählen der ID. In einer Studie von Salt Security waren 94 % aller API-Sicherheitsvorfälle auf diese Schwachstelle zurückzuführen.

Schutz: Jede Ressourcenanfrage muss serverseitig gegen die Nutzer-ID des authentifizierten Tokens geprüft werden. Verwenden Sie UUIDs statt sequenzieller IDs, um Enumeration zu erschweren — aber UUIDs sind kein Ersatz für echte Autorisierungsprüfungen.

Broken Authentication

Schwache Authentifizierungs-Implementierungen ermöglichen Token-Übernahme, Credential Stuffing und Session-Hijacking. Häufige Fehler: Tokens ohne Ablaufdatum, schwache oder hartcodierte JWT-Secrets, fehlende Rate Limits auf Login-Endpunkten, Passwort-Hashes in Response-Bodies.

Excessive Data Exposure

Die API gibt mehr Daten zurück als der Client benötigt und vertraut dem Client, selbst zu filtern. Das Ergebnis: Passwort-Hashes, interne IDs, Sozialversicherungsnummern und persönliche Daten landen im Response-Body — und damit potenziell beim Angreifer. Besonders gefährlich bei mobilen Apps, deren Requests mit Proxy-Tools wie Burp Suite leicht abgefangen werden können.

Fehlende Ressourcen- und Ratenbegrenzung

Ohne Rate Limiting kann ein Angreifer tausende Anfragen pro Minute abfeuern: Brute-Force auf Login-Endpunkte, Enumeration von Nutzer-IDs durch sequenzielle ID-Abfragen, Ressourcenerschöpfung durch komplexe oder berechnungsintensive Abfragen.

Security Misconfiguration

CORS zu freizügig konfiguriert, Debug-Endpoints in Produktion aktiv, Stack-Traces in Fehlerantworten sichtbar, Standard-Passwörter nicht geändert — diese Konfigurationsfehler sind häufiger als man denkt und werden von automatisierten Scannern in Sekunden gefunden.

Authentication und Authorization: Die richtige Implementierung

JWT Best Practices 2026

JSON Web Tokens sind weit verbreitet — und werden häufig falsch implementiert. Die kritischsten Regeln:

// FALSCH: Algorithmus aus dem Token lesen — anfällig für Algorithm Confusion

const decoded = jwt.verify(token, secret);



// RICHTIG: Algorithmus serverseitig fixieren


const decoded = jwt.verify(token, secret, { algorithms: ['HS256'] });

Weitere Pflichtregeln für JWT in der Produktion:

OAuth 2.0: Der richtige Flow

Für Drittanbieter-Zugriffe ist OAuth 2.0 Standard. Für Web- und Mobile-Apps gilt 2026 ausschließlich der Authorization Code Flow mit PKCE (Proof Key for Code Exchange) als empfohlener Flow. Der früher verbreitete Implicit Flow ist deprecated — er überträgt Access Tokens in der URL, die in Browser-Historien, Proxy-Logs und Referrer-Headern landen können.

API Keys für Service-zu-Service-Kommunikation

Rate Limiting: Schicht für Schicht implementieren

Rate Limiting ist keine optionale Performance-Optimierung — es ist fundamentale Sicherheitsmaßnahme. Implementieren Sie es auf mehreren Ebenen gleichzeitig:

# Nginx: Basis-Rate-Limiting pro IP

limit_req_zone $binary_remote_addr zone=api_general:10m rate=30r/m;


limit_req_zone $binary_remote_addr zone=api_login:10m rate=5r/m;



server {


  location /api/auth/login {


    limit_req zone=api_login burst=3 nodelay;


    limit_req_status 429;


  }


  location /api/ {


    limit_req zone=api_general burst=10;


  }


}

Für Anwendungen mit Nutzerkonto braucht es zusätzlich User-basiertes Rate Limiting in der Applikationsschicht. Redis-basierte Implementierungen (express-rate-limit mit Redis-Store in Node.js) funktionieren korrekt über mehrere Server-Instanzen hinweg und sind horizontal skalierbar.

Unterschiedliche Endpunkte benötigen unterschiedliche Limits:

Für DDoS-Schutz auf Netzwerkebene: Ein CDN mit integrierter DDoS-Mitigation wie Cloudflare oder AWS CloudFront fängt volumetrische Angriffe ab, bevor sie Ihren Server überhaupt erreichen. Das ist keine Alternative zu Application-Level-Rate-Limiting, sondern eine ergänzende Schutzschicht.

Input-Validierung: Kein Eingabewert ist vertrauenswürdig

Jeder API-Input ist potenziell feindlich — das ist keine Paranoia, sondern der korrekte Sicherheitsansatz. Schema-Validierung stellt sicher, dass Anfragen exakt die erwartete Struktur, den erwarteten Typ und den erwarteten Wertebereich haben:

// Zod Schema-Validierung (TypeScript/Node.js) — jedes Feld explizit definiert

const CreateOrderSchema = z.object({


  productId: z.string().uuid(),


  quantity: z.number().int().min(1).max(100),


  note: z.string().max(500).optional(),


  deliveryAddress: z.object({


    street: z.string().max(100),


    city: z.string().max(50),


    zip: z.string().regex(/^\d{5}$/)


  })


});



app.post('/api/orders', (req, res) => {


  const result = CreateOrderSchema.safeParse(req.body);


  if (!result.success) {


    // Validierungsfehler zurückgeben, aber keine internen Details


    return res.status(400).json({ error: 'Ungültige Anfrage' });


  }


  // Ausschließlich validierte Daten verarbeiten — nie req.body direkt


  processOrder(result.data);


});

Output-Encoding ist ebenso kritisch: Definieren Sie Response-Schemas explizit. Statt das gesamte Datenbankobjekt zurückzugeben, geben Sie nur die Felder zurück, die der Client tatsächlich benötigt. Data Transfer Objects (DTOs) oder Serializer-Bibliotheken wie class-transformer erzwingen dieses Prinzip systematisch.

HTTPS, CORS und Transport Security

HTTPS ist Pflicht — aber korrekte Konfiguration geht erheblich weiter:

CORS-Konfiguration ist ein häufiger und folgenreicher Schwachpunkt. Wildcard-Origins sind für authentifizierte APIs inakzeptabel. Pflegen Sie eine explizite Whitelist:

Access-Control-Allow-Origin: https://www.pilecode.com

Access-Control-Allow-Methods: GET, POST, PUT, DELETE


Access-Control-Allow-Headers: Content-Type, Authorization


Access-Control-Max-Age: 86400

HTTP Security Headers sind eine einfache, aber wirksame Schutzschicht: X-Content-Type-Options: nosniff verhindert MIME-Sniffing, X-Frame-Options: DENY verhindert Clickjacking, und eine Content-Security-Policy limitiert ladbare externe Ressourcen. Das Paket helmet.js setzt alle wichtigen Headers für Node.js-Anwendungen mit einer einzigen Zeile Code korrekt.

Monitoring und Anomalie-Erkennung in Echtzeit

Erkennen Sie Angriffe, bevor sie erfolgreich sind. Diese Signalmuster deuten auf aktive Angriffe hin:

Wichtig: Logging muss DSGVO-konform sein. Keine Passwörter, vollständige Tokens oder personenbezogene Daten in Logs. Pseudonymisieren Sie sensible Felder konsequent vor der Speicherung.

Ein Incident Response Plan gehört zu jedem professionellen API-Betrieb. Definieren Sie im Voraus: Ab welchem Schwellenwert wird ein Alert ausgelöst? Wie werden kompromittierte Tokens invalidiert? Wer informiert betroffene Nutzer? Die DSGVO verlangt eine Meldung an die Datenschutzbehörde innerhalb von 72 Stunden bei Datenpannen — die Uhr läuft ab dem Moment der Erkenntnis.

Security Testing: APIs systematisch und regelmäßig prüfen

Statische Code-Reviews reichen nicht aus. Führen Sie mehrere Testformen parallel durch:

OWASP ZAP ist ein kostenloses Open-Source-Tool für automatisierte API-Sicherheitstests. Eingebunden in die CI/CD-Pipeline triggert jeder Build automatische Security Scans auf bekannte Schwachstellen aus der OWASP Top 10.

Penetration Testing sollte mindestens einmal jährlich und nach größeren Architekturveränderungen durchgeführt werden. Ein externer Penetrationstest findet Schwachstellen, die interne Teams übersehen — weil sie zu nah am System sind und blinde Flecken haben.

Dependency Scanning: npm audit, snyk oder GitHub Dependabot scannen Ihre Abhängigkeiten kontinuierlich auf bekannte CVEs. Viele API-Schwachstellen entstehen nicht im eigenen Code, sondern in eingebundenen Open-Source-Bibliotheken — und werden erst Monate nach der Erstveröffentlichung entdeckt.

API Fuzzing: Tools wie API Fuzzer oder Postman senden absichtlich unerwartete, fehlerhafte oder extreme Eingaben und prüfen, ob die API korrekt reagiert oder unerwartete Fehler produziert.

Checkliste: Sichere REST-API in der Produktion

Fazit: API-Sicherheit ist ein kontinuierlicher Prozess

Die häufigsten API-Schwachstellen — BOLA, fehlende Autorisierung, kein Rate Limiting, unzureichende Input-Validierung — sind gut dokumentiert und mit den richtigen Werkzeugen und Prozessen zu vermeiden. Die Herausforderung ist nicht das Wissen, sondern die konsequente Umsetzung unter dem täglichen Druck schneller Feature-Entwicklung.

Investieren Sie in API-Sicherheit bevor Sie in Produktion gehen. Ein erfolgreicher Angriff kostet ein Vielfaches der Präventionskosten: Forensik, Wiederherstellung, DSGVO-Bußgelder, Reputationsschäden und verlorenes Kundenvertrauen lassen sich selten vollständig reparieren.

"Security is not a product, but a process." — Bruce Schneier. Sicherheit ist kein einmaliges Setup, sondern ein fortlaufender Prozess aus Design, Implementierung, Testing und regelmäßigen Reviews.

Möchten Sie Ihre APIs auf Sicherheitslücken prüfen lassen? Pilecode bietet professionelle API Security Reviews an — von der Architekturanalyse bis zum Penetrationstest. Jetzt Kontakt aufnehmen.

Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.