Contrôle de sécurité des requêtes API

Collez la requête et les en-têtes de réponse disponibles pour obtenir les observations. L’analyse porte sur ce texte sans interroger l’API.

Fonctionne localement dans votre navigateur
Il s'agit d'une critique locale contenant uniquement du texte. KivTools n’envoie, ne relit ou ne scanne jamais le URL dans votre demande.
Requête ou commande cURL
En-têtes de réponse Facultatif ; collez uniquement les en-têtes, pas un corps de réponse sensible.
Résumé de l'examen
  • Collez une demande et des en-têtes de réponse facultatifs pour examiner les risques API courants.

Un examen ciblé, pas un test d'intrusion

Le vérificateur évalue uniquement le texte copié visible et les règles qui peuvent être évaluées en toute sécurité localement. Il ne peut pas découvrir les failles d'autorisation, les limites de débit, le comportement du serveur ou les vulnérabilités dans un API en direct.

Comment examiner une requête API copiée

Collez la requête HTTP ou la commande cURL telle que copiée, puis, si vous les avez, les en-têtes de réponse. La revue lit ce texte, applique une liste fixe de règles et signale ce qui mérite un second regard.

Tout est calculé dans le navigateur. La requête n’est jamais envoyée, rejouée ni scannée : le trafic de production copié peut donc être examiné sans risque, tant qu’aucun identifiant réel ne reste dans un texte partagé.

  1. Collez la ligne de requête complète avec ses en-têtes (et le corps s’il existe), ou une commande cURL commençant par curl ; les en-têtes de réponse vont dans le second champ.
  2. Cliquez sur Vérifier la demande copiée. Le résumé compte les risques élevés et les points à vérifier, et chaque observation indique l’en-tête ou la partie d’URL concernée.
  3. Lisez d’abord le niveau : une ligne rouge est une combinaison jugée dangereuse par les navigateurs ou les auditeurs, une ligne jaune mérite une vérification.
  4. Cliquez sur Copier l’examen pour récupérer la liste en texte brut, par exemple dans un ticket ; Effacer vide les deux champs pour la requête suivante.
  5. Confirmez sur le serveur ou la passerelle qui répond à l’endpoint tout changement réel : la revue ne voit que le texte collé.

Ce que la revue vérifie et où elle s’arrête

Ce que la revue vérifie

Le transport : cible https, http en clair, un autre schéma comme ftp, ou l’absence de cible absolue.

Les identifiants : secrets dans la query et dans les corps JSON ou de formulaire, utilisateur:motdepasse dans l’URL, authentification Basic dans l’en-tête Authorization ou via un flag -u de cURL, cookies transmis avec -b, et requêtes vers des chemins sensibles sans en-tête Authorization ni X-API-Key.

En-têtes de réponse et cookies

Dans les en-têtes de réponse, la revue lit la combinaison origine CORS et identifiants, les attributs Secure, HttpOnly et SameSite de chaque Set-Cookie, un Content-Type manquant, une redirection vers http et les en-têtes révélant la technologie comme Server ou X-Powered-By.

Une requête avec corps mais sans Content-Type est signalée aussi, et un endpoint d’apparence sensible sans Cache-Control apparaît comme point à vérifier.

Où la revue s’arrête

Les règles ne voient que le texte copié. Elles ne trouvent ni défaut d’autorisation, ni limite de débit, ni comportement serveur, ni vulnérabilité d’une API en production, et un rapport propre n’est pas une garantie de sécurité.

Les valeurs de flags cURL comme -o, -w, -u et -b sont lues comme valeurs de flag, pas comme l’URL, et les commandes avec --header=valeur ou --data=valeur sont comprises ; -I est traité comme une requête HEAD.

Outils récents :