API-Anfragen auf Konfigurationsrisiken prüfen

Fügen Sie die Anfrage und optional die Antwortheader ein. Der Bericht bewertet den vorhandenen Text, ohne den API-Endpunkt aufzurufen.

Läuft lokal in deinem Browser
Dies ist eine rein textbasierte lokale Prüfung. VoriTools sendet, wiederholt und scannt die URL Ihrer Anfrage nicht.
Anfrage oder cURL-Befehl
Response-Header Optional; nur Header einfügen, keinen sensiblen Response-Body.
Prüfzusammenfassung
  • Fügen Sie eine Anfrage und optional Antwort-Header ein, um häufige API-Risiken zu prüfen.

Gezielte Prüfung, kein Penetrationstest

Die Prüfung bewertet nur sichtbaren kopierten Text und lokal sicher beurteilbare Regeln. Sie erkennt weder Autorisierungsfehler, Ratenlimits und Serververhalten noch Schwachstellen einer aktiven API.

So prüfen Sie eine kopierte API-Anfrage

Fügen Sie die HTTP-Anfrage oder den cURL-Befehl genau so ein, wie Sie ihn kopiert haben, und optional die Antwort-Header. Die Prüfung liest diesen Text, wendet eine feste Regelliste an und listet auf, was einen zweiten Blick verdient.

Alles läuft im Browser. Die Anfrage wird nie gesendet, wiederholt oder gescannt; kopierter Produktionsverkehr lässt sich also gefahrlos prüfen, solange keine echten Anmeldedaten in geteiltem Text bleiben.

  1. Fügen Sie die vollständige Anfragezeile mit Headern (und Body, falls vorhanden) oder einen cURL-Befehl, der mit curl beginnt, ein; die Antwort-Header gehören in das zweite Feld.
  2. Klicken Sie auf Kopierte Anfrage prüfen. Die Zusammenfassung zählt Risiken und Prüfpunkte, und jeder Befund nennt den Header oder URL-Teil, aus dem er stammt.
  3. Lesen Sie zuerst die Stufe: Eine rote Zeile ist eine Kombination, die Browser oder Prüfer als unsicher ansehen, eine gelbe verdient eine Kontrolle.
  4. Mit Prüfung kopieren übernehmen Sie die Liste als Text, etwa in ein Ticket; Leeren macht beide Felder für die nächste Anfrage frei.
  5. Bestätigen Sie jede echte Änderung am Server oder Gateway, das den Endpunkt beantwortet – die Prüfung sieht nur den eingefügten Text.

Was die Prüfung untersucht – und wo sie endet

Was die Prüfung untersucht

Transport: ob das Ziel https, einfaches http, ein anderes Schema wie ftp ist oder gar kein absolutes Ziel vorliegt.

Anmeldedaten: Geheimnisse in der Query sowie in JSON- und Form-Bodys, Benutzer:Passwort in der URL, Basic-Authentifizierung im Authorization-Header oder über ein cURL-Flag -u, mit -b übertragene Cookies und Anfragen an sensibel wirkende Pfade ohne Authorization- oder X-API-Key-Header.

Antwort-Header und Cookies

Aus den Antwort-Headern liest die Prüfung die Kombination aus CORS-Ursprung und Anmeldedaten, die Attribute Secure, HttpOnly und SameSite jedes Set-Cookie, einen fehlenden Content-Type, eine Weiterleitung auf http und Technologie-Hinweise wie Server oder X-Powered-By.

Auch eine Anfrage mit Body ohne Content-Type wird gemeldet, und ein sensibel wirkender Endpunkt ohne Cache-Control erscheint als Prüfpunkt.

Wo die Prüfung endet

Die Regeln sehen nur kopierten Text. Autorisierungsfehler, Rate Limits, Serververhalten oder Schwachstellen einer laufenden API kann sie nicht finden, und ein sauberer Bericht ist keine Sicherheitsgarantie.

Flag-Werte wie -o, -w, -u und -b werden als Flag-Werte gelesen, nicht als URL, und Befehle mit --header=Wert oder --data=Wert werden verstanden; -I gilt als HEAD-Anfrage.

Zuletzt verwendet: