Un mode debug contrôlé par le client divulgue le prompt système caché
Le défi
Voici la requête que le widget de chat envoie au backend de l'IA. Le client peut définir un drapeau debug dans le corps, et le serveur le respecte - quand debug est activé, la réponse renvoie le prompt système caché donné au modèle. Activez debug, envoyez, et lisez le flag intégré dans ce prompt divulgué.
Ce que tu vas apprendre
- Reconnaître une faille de divulgation d'informations liée au mode debug sur un endpoint de chat IA
- Repérer un drapeau debug dans le corps d'une requête que le client ne devrait jamais contrôler
- Modifier un champ booléen dans une requête capturée pour révéler l'état caché du serveur
- Lire une réponse d'API pour extraire un prompt système divulgué et le secret qu'il contient
- Expliquer pourquoi la sortie debug et les prompts système doivent être contrôlés côté serveur et jamais renvoyés aux clients
Compétences testées
Prérequis
- Compréhension de base des requêtes HTTP, des corps JSON et des en-têtes d'authentification API
- Connaissance du fait qu'un LLM est piloté par un prompt système caché
Comment ça marche
Les applications basées sur des grands modèles de langage sont pilotées par un prompt système : un bloc d'instructions, une persona, et parfois des secrets que l'opérateur donne au modèle avant le message de l'utilisateur. Ce prompt est une configuration côté serveur. Il peut contenir des noms d'outils internes, des règles de politique, et, comme ici, des jetons de build ou d'intégration, donc il ne doit jamais être renvoyé au client.
Cet endpoint embarquait une fonctionnalité debug qui, une fois activée, joint le contexte brut du modèle, y compris le prompt système, à la réponse. L'erreur est que le drapeau qui la contrôle se trouve dans le corps de la requête, donc n'importe quel appelant peut définir debug=true et recevoir l'état interne. La valeur est un booléen valide ; rien n'est malformé. La faille est qu'une commodité de développement a été reliée à un interrupteur contrôlé par le client et laissée accessible en production.
C'est un cas classique de divulgation d'informations via un chemin de debug oublié, et c'est particulièrement dangereux pour les systèmes d'IA car le prompt système divulgué révèle comment manipuler le modèle et peut contenir des identifiants. La sortie debug doit être protégée par des signaux fiables côté serveur, un drapeau d'environnement, un réseau interne, un rôle opérateur, jamais par un paramètre que l'appelant peut inverser.
Erreurs fréquentes
- Supposer que le drapeau debug est purement cosmétique ou en lecture seule, alors que le serveur modifie réellement sa réponse en fonction de lui.
- Essayer de jailbreaker le modèle avec un message astucieux au lieu de remarquer l'interrupteur debug qui vous donne directement le prompt.
- Envoyer une valeur non booléenne comme
1ouonet abandonner quand le serveur la rejette : le champ est validé comme un booléen, donc il doit êtretrue. - Considérer la fuite comme un mauvais comportement du modèle plutôt que comme la véritable faille : le serveur a joint un état interne à une réponse parce qu'un drapeau contrôlé par le client le lui a demandé.
Comment s'en protéger
Ne laissez jamais un client décider si une sortie interne debug ou détaillée est renvoyée, et n'incluez jamais le prompt système ou une autre configuration côté serveur dans une réponse destinée au client. Protégez toute sortie de diagnostic derrière des signaux fiables côté serveur.
- Pilotez le comportement debug via une variable d'environnement serveur ou un rôle opérateur authentifié, et ignorez tout champ
debugenvoyé par le client. - Retirez le contexte interne (prompt système, nom du modèle, définitions d'outils, jetons) des réponses avant qu'elles ne quittent le serveur.
- Ne mettez jamais de secrets dans le prompt système ; injectez les identifiants au niveau de la couche outil, là où le modèle ne les voit jamais.
- Journalisez et alertez lorsqu'une requête tente d'activer un mode debug ou détaillé, afin que les tentatives soient visibles.