39. Journaux HTTP sans fuite et sans faux contexte

Comprendre le mécanisme

Les logs de trafic et d’authentification doivent permettre de relier un incident à une version, une opération et un résultat. Ils ne doivent pas devenir un inventaire de cookies, Authorization, mots de passe ou corps personnels. Les entrées contrôlées par un client peuvent aussi déformer un journal si elles sont assemblées sans encodage adapté. Un identifiant de corrélation facilite l’enquête, sans prouver à lui seul une identité.

Raisonner et vérifier

Définissez champs, niveaux, accès et conservation selon un besoin précis. Une erreur complète peut rester dans un stockage privé restreint tandis que la réponse publique porte un code stable. Testez les caractères de contrôle, les volumes et les pannes du système de logs. Conservez la capacité de diagnostiquer une demande refusée tôt au proxy, sans augmenter arbitrairement la collecte sensible dans toute la chaîne.

Credentials

Les logs doivent éviter les bearer tokens bruts. Une fuite de log peut alors permettre un rejeu. Un bearer token brut dans les logs devient une copie potentiellement rejouable. Supprimez-le des champs collectés et vérifiez également proxy, APM et exceptions, qui peuvent journaliser la requête automatiquement.

Entrées hostiles

Une structure adaptée aide à encoder les entrées non fiables. Des entrées peuvent déformer la lecture des événements. Utilisez une journalisation structurée avec encodage adapté. Un champ client contenant retour de ligne ou délimiteur ne doit pas pouvoir fabriquer une fausse entrée ou modifier la lecture du contexte.

Corrélation

Un requestId sert à corréler. L’unicité apparente ne prouve pas l’identité. requestId rapproche les événements mais n’authentifie pas l’acteur. Validez ou générez cette référence selon sa provenance et gardez séparée l’identité réellement établie par le mécanisme de sécurité du serveur.

Version

La version déployée aide à situer un incident. La version peut aider sans collecter cette donnée sensible. Associez l’événement à la release et au composant concernés. Cette information aide à relier un incident à une configuration réelle plutôt qu’à une trace ancienne ou à un autre nœud.

Accès

Les droits d’accès aux logs doivent être définis. Les diagnostics peuvent contenir des informations sensibles. Les journaux peuvent révéler comportements et données personnelles même sans mot de passe. Définissez qui peut les lire, exporter et partager, avec une traçabilité adaptée aux besoins d’exploitation.

Conservation

Une durée de conservation doit être justifiée. Les besoins et risques de collecte doivent être maîtrisés. Choisissez durée et finalité au lieu de conserver indéfiniment par défaut. Les exports et sauvegardes participent aussi à cette conservation ; une suppression du store actif ne retire pas toutes les copies.

Panne de collecte

Les pannes de journalisation doivent être prévues. Disque, débit et services distants peuvent échouer. Prévoyez saturation, indisponibilité et erreurs du pipeline de logs. Le service doit avoir une politique explicite : la journalisation ne doit pas bloquer sans borne ni masquer silencieusement des événements indispensables.

Avant l’application

Le proxy peut journaliser un refus avant l’application. Un refus peut se situer en amont. Un 413 peut être journalisé uniquement au proxy. Corrélez les couches et n’interprétez pas l’absence de trace PHP comme une preuve que le navigateur n’a émis aucune demande.

Public et privé

Le diagnostic public peut rester plus limité que le privé. Les besoins d’accès et de confidentialité diffèrent. Le client peut recevoir une catégorie stable et un identifiant, tandis que le support consulte un diagnostic protégé. Ne publiez pas la trace interne pour faciliter une investigation ponctuelle.

Partage expurgé

Les preuves doivent être expurgées avant partage. Les fixtures et résultats peuvent être sans données réelles. Avant de joindre une preuve à un ticket, retirez cookies, tokens et données clientes inutiles. Vérifiez le fichier final, y compris captures et champs masqués seulement visuellement dans l’outil d’origine.

Atelier guidé : lire, expliquer et vérifier le code

{
  "requestId": "lab-42",
  "operation": "orders.read",
  "Authorization": "Bearer public-fixture-only",
  "result": "denied"
}

Le champ Authorization contient la valeur complète, même si la fixture est publique. Dans une demande réelle, ce modèle de journalisation créerait une copie de credential. Remplacez-le par une catégorie de mécanisme et un résultat minimisé, puis vérifiez que la valeur ne réapparaît pas dans les exceptions ou traces automatiques.

L’opération générique peut être utile selon la politique. Le format JSON ne constitue pas la donnée sensible montrée. Un bearer token peut devenir une capacité rejouable si le log fuite. Le résultat aide au diagnostic sans imposer ce secret.

Travail pratique : Produisez une matrice de journalisation pour succès, refus de droit, 413 et timeout. Ajoutez une entrée client contenant un retour à la ligne fictif.

Critères de correction : Vérifiez la structure de l’événement et l’absence de secret. Comparez journaux proxy et application avec une corrélation bornée. Testez la politique de conservation et la visibilité des diagnostics selon le rôle d’exploitation.

Événements d’authentification utiles sans secrets

Pour comprendre des échecs de connexion, conservez résultat, catégorie de mécanisme, horodatage, composant et corrélation non sensible. Un token ou un mot de passe brut n’est pas nécessaire pour compter les refus et retrouver le chemin d’un incident.

Utilisez des événements structurés et encodez les valeurs non fiables afin qu’un nom contenant un retour de ligne ne fabrique pas une autre entrée. Protégez accès, intégrité et durée de conservation ; les journaux peuvent rester sensibles même après suppression des credentials.

Vérifiez toute la collecte : proxy, application, exceptions et APM peuvent enregistrer la même demande selon des règles différentes. Une liste noire dans un seul logger ne garantit pas l’absence de copies ailleurs. Avec une fixture identifiable, provoquez un refus et inspectez les artefacts finaux. Avant partage dans un ticket, expurgez de nouveau les preuves et ne considérez pas un requestId fourni par le client comme une identité authentifiée.

Points de vigilance : Les tokens, cookies et mots de passe peuvent devenir des moyens d’usurpation dans les logs. L’absence de traces empêche de détecter et d’investiguer les attaques. La minimisation préserve les signaux utiles ; les données non fiables doivent aussi être encodées pour éviter l’injection de logs. D’autres données et secrets restent exposés ; la confidentialité exige un contrôle global des accès.