OWASP API Security Top 10: Checkliste mit Korrekturen

API4:2023 Uneingeschränkter Ressourcenverbrauch

APIs, die unbegrenzte Anfragen akzeptieren, ermöglichen es Angreifern, Ihre Infrastrukturrechnung in die Höhe zu treiben und Ihre Datenbank zu erschöpfen Verbindungen zerstören oder einen Denial-of-Service auslösen. Dies gilt für fehlende Ratengrenzen und unbegrenzte Abfragen Parameter (z. B. ?limit=1000000), Datei-Uploads ohne Größenbeschränkung und Endpunkte teure Hintergrundjobs auslösen.

Angriffsszenario: Ein API-Endpunkt generiert PDF-Berichte. Ein Angreifer sendet 500 gleichzeitige Anfragen, bei denen jeweils ein 200-seitiger Bericht angefordert wird. Ihr Arbeitskräftepool ist voll und legitim Benutzer erhalten in den nächsten 20 Minuten 503-Fehler.

Fix: Fügen Sie eine Ratenbegrenzung pro Benutzer und pro IP hinzu. Begrenzen Sie die Paginierungsgrenzen serverseitig Höchstwerte. Legen Sie Größenbeschränkungen für Datei-Uploads fest. Nutzen Sie die warteschlangenbasierte Verarbeitung für teure Vorgänge.

// Express rate limiter per user
import rateLimit from "express-rate-limit";

const apiLimiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 30,             // 30 requests per minute per IP
  standardHeaders: true,
  legacyHeaders: false,
  message: { error: "Rate limit exceeded. Try again in 60 seconds." },
});

app.use("/api/", apiLimiter);

API5:2023 Autorisierung auf Funktionsebene fehlerhaft

Durch Autorisierungsfehler auf Funktionsebene können normale Benutzer Administratorendpunkte aufrufen. Das typische Muster: an Admin-Panel-Aufrufe DELETE /api/admin/users/:id. Das Frontend verbirgt den Button vor Nicht-Administratorbenutzer, aber der API-Endpunkt selbst überprüft keine Rollen. Jeder authentifizierte Benutzer, der entdeckt, dass die URL Konten löschen kann.

Angriffsszenario: Ein Entwickler findet /api/admin/export-all-users im JavaScript-Bundle. Sie rufen es mit ihrem regulären Benutzertoken auf und laden den vollständigen Benutzer herunter Datenbank.

Fix: Überprüfen Sie die Rolle des Benutzers auf der API-Ebene für jeden Admin-Endpunkt. Verlassen Sie sich nicht darauf das Frontend, um Funktionen auszublenden. Gruppenadministratorrouten hinter Middleware, die die Überprüfung durchführt role === "admin" vor der Bearbeitung der Anfrage.

API6:2023 Uneingeschränkter Zugriff auf sensible Geschäftsabläufe

Einige API-Abläufe sind im großen Maßstab gefährlich, selbst wenn jede einzelne Anfrage autorisiert ist. Kaufen Artikel mit begrenztem Lagerbestand, Erstellung kostenloser Testkonten, Übermittlung von Empfehlungscodes; diese Ströme Pause, wenn automatisiert. Ein Bot eröffnet 10.000 kostenlose Konten oder kauft jedes Ticket in einem Flash-Sale bevor ein echter Benutzer die Seite lädt.

Angriffsszenario: Ein Sneaker-Reseller schreibt einen Bot, der anruft POST /api/checkout 500 Mal in der ersten Sekunde eines begrenzten Drops. Jedes Paar verkauft sich zu Bots. Menschliche Kunden sehen „ausverkauft“, bevor die Seite vollständig geladen ist.

Fix: Fügen Sie CAPTCHA- oder Proof-of-Work-Herausforderungen zu hochwertigen Flows hinzu. Gerät verfolgen Fingerabdrücke zur Erkennung von Automatisierung. Legen Sie Kauflimits pro Benutzer fest. Verwenden Sie den warteschlangenbasierten Zugriff für Flash-Sales anstelle von „Wer zuerst kommt, mahlt zuerst“-Endpunkten.

API7:2023 Serverseitige Anforderungsfälschung (SSRF)

SSRF geschieht, wenn eine API eine URL vom Client akzeptiert und sie serverseitig ohne abruft Validierung des Ziels. Ein Angreifer stellt bereit http://169.254.169.254/latest/meta-data/ und Ihr Server gibt die Anmeldeinformationen der AWS-Instanz zurück. Oder sie zielen darauf ab http://localhost:6379/ und interagieren Sie mit Ihrer Redis-Instanz.

Angriffsszenario: Bei einer Webhook-Integration können Benutzer eine Rückruf-URL angeben. Ein Angreifer setzt den Rückruf auf http://169.254.169.254/latest/meta-data/iam/security-credentials/ und erhält die IAM-Rollenanmeldeinformationen Ihres Cloud-Anbieters in der Webhook-Nutzlast.

// Block internal network requests
const BLOCKED_RANGES = [
  /^10\\./, /^172\\.(1[6-9]|2\\d|3[01])\\./, /^192\\.168\\./,
  /^127\\./, /^0\\./, /^169\\.254\\./,
  /^localhost$/i, /^\\[::1\\]$/,
];

function isSafeUrl(urlString) {
  try {
    const url = new URL(urlString);
    const hostname = url.hostname;
    return !BLOCKED_RANGES.some((re) => re.test(hostname));
  } catch {
    return false;
  }
}

app.post("/api/fetch-url", async (req, res) => {
  const { url } = req.body;
  if (!isSafeUrl(url)) {
    return res.status(400).json({ error: "URL targets a blocked network range" });
  }
  // proceed with external fetch
});

Fix: Ziel-URLs validieren und auf die Zulassungsliste setzen. Blockieren Sie private IP-Bereiche und Cloud Metadaten-Endpunkte. Lösen Sie DNS auf, bevor Sie die Anfrage stellen, um eine erneute DNS-Bindung zu verhindern. Ausgehend ausführen Anfragen von einem isolierten Netzwerksegment.

API8:2023 Sicherheitsfehlkonfiguration

Fehlkonfiguration ist die umfassendste Risikokategorie. Es enthält fehlende CORS-Einschränkungen und ausführliche Fehler Nachrichten, die Stack-Traces preisgeben, Standardanmeldeinformationen in Admin-Panels, unnötige HTTP-Methoden aktiviert, TLS wird nicht erzwungen und es fehlen Sicherheitsheader. Jede einzelne Fehlkonfiguration schafft einen Einstiegspunkt.

Angriffsszenario: Eine API gibt vollständige Stack-Traces in Produktionsfehlerantworten zurück. Ein Angreifer löst absichtlich Fehler aus, liest die Stack-Traces aus, identifiziert die ORM- und Datenbankversion, erstellt dann eine Injektionsnutzlast basierend auf bekannten Schwachstellen in dieser Version.

Fix: Entfernen Sie Stapelspuren aus Produktionsantworten. Stellen Sie CORS so ein, dass nur Ihre Domänen zugelassen werden. Deaktivieren Sie HTTP-Methoden, die Sie nicht verwenden. Setzen Sie TLS überall durch. Führen Sie automatisierte Sicherheits-Header-Prüfungen durch. Bereinigen Sie alle HTML-Ausgaben, um XSS zu verhindern.

Der veröffentlichte HTML-Bereinigungs-API Streifen bösartige Tags und Attribute aus vom Benutzer bereitgestelltem HTML:

curl -s -X POST https://api.botoi.com/v1/html-sanitize \\
  -H "Content-Type: application/json" \\
  -d '{
    "html": "<p>Hello</p><script>document.cookie</script><img onerror=alert(1) src=x>"
  }'

Antwort:

{
  "success": true,
  "data": {
    "sanitized": "<p>Hello</p><img src=\\"x\\">"
  }
}

Der <script> Tag und die onerror Attribut werden entfernt. Das sichere HTML wird zurückgegeben. Rufen Sie diesen Endpunkt auf, bevor Sie vom Benutzer bereitgestelltes HTML speichern oder rendern.

API9:2023 Unsachgemäße Bestandsverwaltung

Alte API-Versionen, vergessene Staging-Endpunkte und undokumentierte Routen schaffen Angriffsfläche für Sie nicht überwachen. Angreifer suchen nach /v1/, /v2/, /api-dev/, Und /internal/ Wege. Sie finden einen veralteten Endpunkt, dem die Sicherheitskontrollen fehlen Sie haben zur aktuellen Version hinzugefügt.

Angriffsszenario: Ihr Team hat versendet /v2/users mit rollenbasiertem Zugriff Kontrolle. Aber /v1/users läuft immer noch ohne Genehmigung in der Produktion. Ein Angreifer Ermittelt den v1-Pfad über eine öffentliche Swagger-Datei und ruft die gesamte Benutzertabelle ab.

Fix: Pflegen Sie ein vollständiges API-Inventar. Alte Versionen außer Betrieb nehmen; verlass sie nicht läuft „für den Fall, dass jemand sie noch verwendet.“ Schützen Sie jede Version hinter derselben Authentifizierungs-Middleware. Scannen Ihre eigene Infrastruktur für exponierte Wege in regelmäßigen Abständen.

API10:2023 Unsicherer Verbrauch von APIs

Ihre API ruft Dienste von Drittanbietern auf: Zahlungsabwickler, E-Mail-Anbieter, Geokodierungs-APIs. Wenn Sie Wenn Sie ihren Antworten ohne Validierung vertrauen, kann ein kompromittierter oder böswilliger Dritter Daten einschleusen in Ihr System ein. Dazu gehört das Vertrauen von Weiterleitungs-URLs, das Parsen von nicht validiertem JSON oder das Speichern Antworten Dritter ohne Bereinigung.

Angriffsszenario: Ihre App ruft Unternehmensdaten von einer Anreicherungs-API eines Drittanbieters ab und speichert die company_name Feld direkt in Ihrer Datenbank. Die Anreicherungs-API erhält kompromittiert und der Angreifer injiziert <script> Tags in Firmennamen. Jeder Ein Benutzer, der ein Unternehmensprofil in Ihrem Dashboard anzeigt, führt das Skript aus.

Fix: Überprüfen und bereinigen Sie alle Antworten von Drittanbietern, bevor Sie sie speichern oder rendern sie. Verwenden Sie die Schemavalidierung für eingehende Daten. Legen Sie Timeouts für externe Anrufe fest. Wenden Sie die gleiche Eingabe an Validierung von Daten Dritter, die Sie auf Benutzereingaben anwenden.

Erkennen Sie die Offenlegung sensibler Daten in Ihren API-Antworten

Die Risiken API1 und API3 führen häufig dazu, dass sensible Daten Ihre API verlassen. Der botoi PII-Erkennungs-API scannt Text nach Sozialversicherungsnummern, Kreditkartennummern, E-Mail-Adressen, Telefonnummern, IP-Adressen usw Geburtsdaten. Führen Sie es in Integrationstests mit Ihren API-Antwortkörpern aus, um versehentliche Fehler zu erkennen Datenlecks vor der Bereitstellung.

curl -s -X POST https://api.botoi.com/v1/pii/detect \\
  -H "Content-Type: application/json" \\
  -d '{
    "text": "Customer SSN is 123-45-6789 and card is 4111111111111111"
  }'

Antwort:

{
  "success": true,
  "data": {
    "found": true,
    "count": 2,
    "findings": [
      {
        "type": "ssn",
        "value": "123-45-6789",
        "start": 17,
        "end": 28,
        "masked": "***-**-6789"
      },
      {
        "type": "credit_card",
        "value": "4111111111111111",
        "start": 42,
        "end": 58,
        "masked": "************1111"
      }
    ]
  }
}

Wenn Ihre API-Antwort Ergebnisse auslöst, gibt Ihr Endpunkt Daten zurück, die der Client nicht sehen sollte. Korrigieren Sie die Abfrage oder das DTO, um diese Felder auszuschließen.

Verschlüsseln Sie vertrauliche Daten im Ruhezustand

Wenn Ihre API vertrauliche Konfigurationen, Token oder Anmeldeinformationen speichert, verschlüsseln Sie diese vor dem Schreiben zur Datenbank. Der Botoi-Verschlüsselungs-API bietet AES-256-CBC-Verschlüsselung:

curl -s -X POST https://api.botoi.com/v1/encrypt/encrypt \\
  -H "Content-Type: application/json" \\
  -d '{
    "text": "sensitive-api-token-abc123",
    "password": "your-secret-key"
  }'

Antwort:

{
  "success": true,
  "data": {
    "encrypted": "U2FsdGVkX1+abc...encrypted_output_here",
    "algorithm": "aes-256-cbc"
  }
}

Speichern Sie die verschlüsselte Ausgabe. Entschlüsseln mit /v1/encrypt/decrypt nur wenn der Wert ist benötigt. Dadurch wird der Explosionsradius begrenzt, wenn ein Angreifer über einen Lesezugriff auf Ihre Datenbank erhält BOLA- oder SQL-Injection-Schwachstelle.

Die OWASP-API-Sicherheits-Top-10-Checkliste

Drucken Sie diese Tabelle aus oder fügen Sie sie Ihrer Sicherheitsüberprüfungsvorlage hinzu. Überprüfen Sie jedes Element vor jeder API-Veröffentlichung.

Wohin von hier aus?

Die vollständige OWASP API Security Top 10-Dokumentation finden Sie unter owasp.org/API-Security. Jede Risikoseite enthält Erkennungsmethoden, Beispielangriffsszenarien und Verweise auf CWEs.

Für automatisierte Prüfungen integrieren Sie die oben genannten Botoi-Endpunkte in Ihre CI-Pipeline. Führen Sie die PII-Erkennung aus gegen API-Antwortvorrichtungen. Bereinigen Sie gespeichertes HTML beim Schreiben. Überprüfen Sie die E-Mails neuer Benutzer auf Verstöße Datenbanken während der Anmeldung. Hierbei handelt es sich um kleine Ergänzungen zu Ihrer Testsuite, die die Risikoscanner erfassen Fräulein.