Security of logs

Imaginez que votre application vient d’être compromise. Les attaquants sont entrés, ont peut-être exfiltré des données, et sont repartis. Votre première réaction ? Aller consulter les logs.

Sauf que les logs ont été effacés. Ou pire : ils étaient incomplets depuis le début.

C’est le paradoxe des logs. Indispensables pour reconstruire une chronologie lors d’un incident, ils peuvent eux-mêmes devenir une source de fuite de données, un vecteur d’attaque, ou un risque réglementaire qu’on ne voit pas venir si on ne les a pas pensés correctement.

Les exemples concrets ne manquent pas. En 2022, GitHub révélait dans un post-mortem public que des mots de passe en clair d’utilisateurs npm avaient été enregistrés par erreur dans des fichiers de logs internes. En 2023, Okta découvrait que des fichiers de support uploadés par ses clients contenaient des tokens de session actifs. Résultat : des comptes administrateurs compromis chez plusieurs clients, dont 1Password, BeyondTrust et Cloudflare. Et 19 jours s’étaient écoulés avant que la compromission ne soit détectée, en partie parce que les logs du système de support étaient incomplets.

Des logs bien pensés dès le départ coûtent peu. Des logs mal pensés peuvent coûter très cher, financièrement, légalement, en termes de réputation. Dans cet article, on passe en revue pourquoi il faut sécuriser ses logs, et quoi logger, ou surtout ne jamais logger.

Partie 1 : Pourquoi sécuriser ses logs ?

1.1 Les risques concrets

La sécurisation des logs, c’est d’abord une question d’exposition réelle. Pas uniquement de conformité.

Les données personnelles loggées par erreur

C’est probablement le risque le plus fréquent, et le moins intentionnel. Un développeur logue l’objet de requête complet pour faciliter le debug. Une réponse d’API est tracée intégralement « pour voir ce qui se passe en prod ». Un formulaire de connexion est loggué avant validation.

Résultat : des adresses email, des tokens d’authentification, parfois des mots de passe en clair se retrouvent dans des fichiers de logs, souvent peu protégés, parfois accessibles à toute l’équipe, parfois archivés indéfiniment.

Les logs comme vecteur de reconnaissance

Un attaquant qui accède à vos logs n’a pas seulement accès à des données. Il a accès à une cartographie de votre architecture : quels services communiquent entre eux, quelles
erreurs sont récurrentes, quelles routes sont les plus sensibles. Des logs bien remplis sont une mine d’informations pour quelqu’un qui cherche un point d’entrée.

La log injection

Moins connue que l’injection SQL, la log injection suit le même principe. Un attaquant insère des caractères spéciaux ou des retours à la ligne dans une entrée utilisateur, un nom d’utilisateur, un champ de formulaire, pour forger de fausses entrées dans vos logs. Il peut ainsi simuler des événements légitimes, noyer de vraies alertes dans le bruit, ou corrompre un parser de logs.

La destruction des traces

Lors d’une intrusion, effacer ses traces est souvent l’une des premières actions d’un attaquant. Si vos logs sont modifiables par les systèmes qui les produisent, ou par les comptes compromis, ils disparaissent avec lui. Sans traces, pas d’investigation possible, pas de chronologie reconstituable, pas de preuve recevable.

Le sur-logging

À l’inverse, trop logger crée ses propres problèmes. Des logs trop verbeux augmentent les coûts de stockage, mais surtout ils noient les événements critiques dans le bruit. Une alerte de sécurité enfouie dans des milliers de lignes de debug a peu de chances d’être détectée à temps. Et paradoxalement, plus on logue, plus on augmente la surface d’exposition : chaque donnée supplémentaire est une donnée de plus qui peut fuiter.

La juste mesure est donc aussi un enjeu de sécurité.

1.2 Les obligations légales

La gestion des logs est encadrée par plusieurs textes. Voici les principaux.

Le RGPD et la CNIL

Ce que beaucoup d’équipes ignorent : les logs sont un traitement de données personnelles à part entière. Une adresse IP, un identifiant utilisateur, une heure de connexion, ce sont des données personnelles au sens du RGPD dès lors qu’elles permettent d’identifier une personne, directement ou indirectement.

À ce titre, ils sont soumis aux mêmes principes que n’importe quel autre traitement : minimisation des données, durée de conservation définie et justifiée, sécurité adaptée. La CNIL est explicite là-dessus dans sa fiche dédiée à la journalisation.

Les sanctions sont concrètes. En janvier 2024, PAP (pap.fr) écopait de 100 000 euros d’amende notamment pour conservation excessive de données et défauts de sécurité. En janvier 2026, Free et Free Mobile se voyaient infliger 42 millions d’euros au total, avec parmi les manquements retenus des mesures de détection des comportements anormaux jugées inefficaces, permettant à l’attaquant d’accéder aux données pendant près d’un mois sans être détecté, et la conservation de millions de données d’anciens abonnés bien au-delà de la durée légale.

NIS2

La directive européenne NIS2, en cours de transposition en droit français, concerne les entités « essentielles » et « importantes » : opérateurs de services numériques, administrations, secteurs critiques comme l’énergie, la santé, les transports ou la finance. Pour ces structures, la journalisation des événements de sécurité n’est plus optionnelle, c’est une obligation, avec des exigences précises sur la détection des incidents et leur documentation.
Si vous travaillez dans ce périmètre, ou pour des clients qui y sont, c’est un point à creuser.

Partie 2 : Quoi logger (et quoi ne jamais logger)

2.1 Les événements qui comptent

Tous les logs ne se ressemblent pas. Avant de décider quoi logger, il est utile de distinguer deux grandes familles : les événements de sécurité, qui tracent ce qui se passe sur votre système du point de vue des accès et des actions sensibles, et les logs de debug, qui aident à comprendre le comportement technique de l’application.

Ces deux types de logs n’ont pas les mêmes destinataires, pas le même cycle de vie, et pas les mêmes exigences de sécurité. Un log de debug est temporaire, verbeux, destiné aux développeurs. Un événement de sécurité est permanent, structuré, potentiellement requis comme élément de preuve. Les traiter de la même façon est l’une des erreurs les plus fréquentes.

Plus précisément, on peut classer les logs en quatre niveaux de sensibilité, avec des
implications différentes sur la rétention, le chiffrement et les droits d’accès :

Type de log	Exemples	Sensibilité	Accès
Logs de debug	Traces d’exécution, erreurs techniques, requêtes SQL	Faible	Equipe dev
Logs applicatifs métier	Connexions, actions utilisateurs, erreurs fonctionnelles	Moyenne	Equipe dev, ops
Logs IAM / PAM	Accès aux comptes privilégiés, élévations de droits, modifications de permissions	Elevée	Equipe sécu, admin
Logs de sécurité	Tentatives d’intrusion, échecs d’authentification répétés, accès anormaux	Critique	Equipe sécu, RSSI

Cette classification n’est pas qu’organisationnelle. Elle conditionne directement les choix techniques abordés en partie 3 : durée de rétention, chiffrement, contrôle d’accès.

2.2 Ce qu’il ne faut jamais logger

Certaines données ne doivent tout simplement pas se retrouver dans vos logs, quelles que soient les circonstances.

Les plus évidentes : mots de passe, tokens d’authentification, clés API, numéros de carte bancaire, données de santé. L’incident GitHub mentionné en introduction en est l’illustration directe.

Moins évident mais tout aussi risqué : les réponses d’API complètes. Il est tentant de les logger intégralement pour faciliter le debug, mais une réponse d’API peut contenir des données personnelles, des tokens, ou des informations sensibles qu’on n’a pas anticipées au moment de la mise en place du log.

Les niveaux de log et les environnements

Ce qui est acceptable en développement local ne l’est pas en production. Un niveau DEBUG activé en prod, c’est une surface d’exposition inutile. En production, seuls les niveaux WARNING, ERROR et les événements de sécurité explicitement définis ont leur place.

Attention également aux pipelines CI/CD. Les variables d’environnement sont souvent incluses par défaut dans les logs de build : si un job affiche ces logs durant son exécution, les secrets qu’ils contiennent, mots de passe ou clés API, se retrouvent exposés. Ces logs sont souvent accessibles à toute l’équipe sans contrôle particulier. Un angle mort classique.

2.3 La qualité d’un bon événement de log

Un bon événement de log, c’est avant tout un événement prévisible et structuré. A minima, il devrait contenir :
• un timestamp fiable
• un niveau de sévérité
• un identifiant de corrélation pour relier les événements entre eux
• un contexte utilisateur pseudonymisé, jamais de données personnelles en clair
• une description de l’action et son résultat

Sur le timestamp : un horodatage incorrect ou désynchronisé rend la reconstitution d’une chronologie d’incident très difficile, voire impossible. En contexte cloud, NTP est configuré par défaut, ce n’est généralement pas le problème. L’angle mort classique, c’est l’incohérence des fuseaux horaires entre services. UTC partout, sans exception.

Le standard OWASP Logging Vocabulary

Il existe un standard qui va plus loin, peu connu des développeurs : l’OWASP Logging Vocabulary Cheat Sheet. Il propose une nomenclature standardisée pour les événements de sécurité : authn_login_fail, authz_fail, input_valid_fail… L’idée est simple : si toutes vos applications utilisent les mêmes noms d’événements, la détection automatique et la corrélation entre services deviennent beaucoup plus efficaces. Ce n’est pas un outil, juste une convention. Mais une convention qui a de la valeur, surtout dans un contexte multi services.

Conclusion

Les risques abordés dans cet article ont en commun de ne pas nécessiter d’outillage sophistiqué pour exister. Des données personnelles loggées par erreur, un niveau DEBUG laissé actif en production, des tokens qui traînent dans des réponses d’API tracées intégralement : ce sont des angles morts fréquents, souvent installés dès les premières semaines d’un projet, et rarement revisités.

Un bon point de départ, faisable aujourd’hui : lancer une recherche dans vos logs de production sur des patterns comme password, token, secret, authorization. Pas pour trouver des coupables, mais pour avoir une image honnête de l’état réel des choses. Ce que vous trouvez dans les cinq premières minutes dit généralement beaucoup sur la maturité du sujet dans votre équipe.

Savoir quoi ne pas logger est une condition nécessaire, mais pas suffisante. Il reste à protéger ce qu’on garde : comment architecturer le stockage, garantir l’intégrité des traces, définir des durées de conservation cohérentes. C’est l’objet d’un second article, qui aborde aussi pourquoi centraliser ses logs transforme une bonne pratique en véritable capacité de détection.