Journalisation (A09) et gestion des erreurs (A10) : analyser les logs

La journalisation consiste à enregistrer, dans des journaux (logs), les événements qui permettent de détecter une attaque, d'enquêter après un incident et de prouver qui a fait quoi. Ce chapitre couvre deux catégories du Top 10 2025 : les défaillances de journalisation et d'alerte (A09), et la mauvaise gestion des conditions exceptionnelles (A10), nouvelle en 2025. Il montre quoi journaliser, comment écrire un journal exploitable, comment analyser les connexions à la main et en SQL, et comment gérer les erreurs sans ouvrir de faille.

Pourquoi journaliser

Une attaque qui n'est pas vue dure. Sans journaux, une intrusion peut rester invisible pendant des mois, et quand on la découvre, on ne sait ni par où l'attaquant est entré, ni ce qu'il a lu, ni s'il est encore là. Les journaux servent à :

• détecter : repérer une force brute, une énumération, une injection en cours ;
• enquêter : reconstituer le déroulement d'un incident, mesurer son étendue (quelles données, quels comptes), répondre aux obligations de notification du RGPD ;
• prouver : le critère P de DICP. Savoir qui a validé une fiche, qui a consulté un RIB, et pouvoir le démontrer.

L'OWASP a renommé la catégorie A09 en 2025 pour insister sur l'alerte : un journal que personne ne lit ne protège rien. Il faut que certains événements préviennent quelqu'un.

Quels événements journaliser

Ce qu'il ne faut jamais écrire dans un journal : les mots de passe (même erronés : une faute de frappe révèle souvent le vrai mot de passe), les jetons de session, les jetons JWT et de réinitialisation, les clés d'API, les numéros de carte bancaire, et plus largement les données personnelles qui ne sont pas nécessaires. Un journal est lu par plus de personnes que la base, conservé ailleurs, sauvegardé : une donnée sensible qui y entre fuit.

Un bon journal

La CNIL, dans sa recommandation de 2021 sur la journalisation, attend que chaque trace permette d'identifier individuellement l'auteur, l'horodatage, l'équipement utilisé et la nature de l'opération. Une ligne utile répond à : qui, quand, d'où, quoi, sur quelle ressource, avec quel résultat.

On préfère un journal structuré (une ligne JSON par événement) à une phrase libre : il se filtre et s'agrège facilement, et un login piégé contenant un retour à la ligne ne peut pas fabriquer une fausse ligne. Avec la bibliothèque pino en Node.js :

import pino from 'pino';

const journal = pino({
  redact: ['req.headers.authorization', 'req.headers.cookie', 'mdp'],   // masque ces champs
});

export function journaliserSecurite(evenement, req, details = {}) {
  journal.info({
    evenement,
    utilisateur: req.utilisateur?.id ?? null,
    ip: req.ip,
    route: `${req.method} ${req.originalUrl}`,
    ...details,
  });
}

// Dans la route de lecture d'une fiche, en cas de refus :
journaliserSecurite('acces_refuse', req, { ressource: `fiche:${req.params.id}` });

{"level":30,"time":1773303669412,"evenement":"acces_refuse","utilisateur":17,"ip":"10.0.2.18","route":"GET /api/fiches/1188","ressource":"fiche:1188"}

Les journaux applicatifs peuvent aussi aller dans une table de la base, comme dans plusieurs sujets d'E7. La table journal d'AppliFrais :

CREATE TABLE journal (
  id INT AUTO_INCREMENT PRIMARY KEY,
  date_heure DATETIME NOT NULL,
  login VARCHAR(50),
  ip VARCHAR(45) NOT NULL,           -- 45 caractères : la longueur maximale d'une adresse IPv6 écrite en texte
  action VARCHAR(30) NOT NULL,
  ressource VARCHAR(50),
  resultat ENUM('succes', 'echec') NOT NULL
);

Protéger les journaux. Un attaquant qui a pris pied sur le serveur cherche à effacer ses traces. Les journaux doivent donc être envoyés vers un serveur séparé (serveur syslog, plateforme de centralisation), avec des droits en écriture seule pour l'application (le compte SQL de l'application a INSERT sur journal, mais ni UPDATE ni DELETE), et des accès en lecture limités et eux-mêmes tracés. Les serveurs doivent être à l'heure (NTP), sinon les traces de plusieurs machines ne se recoupent pas.

Les conserver le temps qu'il faut. La CNIL recommande une durée de conservation des journaux comprise entre six mois et un an, sauf obligation légale ou besoin justifié (un incident en cours d'enquête, par exemple). Les journaux contiennent des données personnelles (logins, adresses IP) : ils ne servent qu'à la sécurité, pas à surveiller l'activité des salariés.

Lire un journal d'accès

Le serveur web (nginx, Apache) enregistre chaque requête dans son journal d'accès, au format dit combined :

10.0.2.31 - - [12/Mar/2026:08:48:02 +0100] "GET /api/fiches?mois=202603 HTTP/1.1" 200 1893 "https://frais.gsb.local/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

Voici un extrait du journal d'accès d'AppliFrais, le 12 mars 2026 au matin :

10.0.2.31 - - [12/Mar/2026:08:47:30 +0100] "POST /api/connexion HTTP/1.1" 200 412 "https://frais.gsb.local/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
10.0.2.31 - - [12/Mar/2026:08:48:02 +0100] "GET /api/fiches?mois=202603 HTTP/1.1" 200 1893 "https://frais.gsb.local/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
198.51.100.23 - - [12/Mar/2026:09:12:40 +0100] "GET /.env HTTP/1.1" 404 153 "-" "Mozilla/5.0 zgrab/0.x"
198.51.100.23 - - [12/Mar/2026:09:12:41 +0100] "GET /.git/config HTTP/1.1" 404 153 "-" "Mozilla/5.0 zgrab/0.x"
198.51.100.23 - - [12/Mar/2026:09:12:41 +0100] "GET /phpmyadmin/ HTTP/1.1" 404 153 "-" "Mozilla/5.0 zgrab/0.x"
203.0.113.80 - - [12/Mar/2026:09:20:11 +0100] "GET /api/fiches?mois=202603%27%20UNION%20SELECT%20login,mdp_hash%20FROM%20utilisateur--%20 HTTP/1.1" 400 61 "-" "sqlmap/1.9"
203.0.113.80 - - [12/Mar/2026:09:20:12 +0100] "GET /api/justificatifs?fichier=..%2F..%2F..%2Fetc%2Fpasswd HTTP/1.1" 400 61 "-" "sqlmap/1.9"
10.0.2.18 - - [12/Mar/2026:09:21:05 +0100] "GET /api/fiches/1187 HTTP/1.1" 200 734 "https://frais.gsb.local/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5)"
10.0.2.18 - - [12/Mar/2026:09:21:09 +0100] "GET /api/fiches/1188 HTTP/1.1" 404 30 "https://frais.gsb.local/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5)"
10.0.2.18 - - [12/Mar/2026:09:21:10 +0100] "GET /api/fiches/1189 HTTP/1.1" 404 30 "https://frais.gsb.local/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5)"
10.0.2.18 - - [12/Mar/2026:09:21:11 +0100] "GET /api/fiches/1190 HTTP/1.1" 404 30 "https://frais.gsb.local/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5)"
198.51.100.23 - - [12/Mar/2026:09:22:30 +0100] "GET /wp-login.php HTTP/1.1" 404 153 "-" "Mozilla/5.0 zgrab/0.x"

On y lit trois histoires :

• 198.51.100.23 parcourt des adresses classiques (/.env, /.git/config, /phpmyadmin/, /wp-login.php) : un scanner automatique qui cherche des fichiers oubliés. Tout répond 404 : rien n'a fuité. C'est le bruit de fond d'Internet.
• 203.0.113.80 envoie une injection SQL (%27 est l'apostrophe encodée, suivie de UNION SELECT login,mdp_hash FROM utilisateur) puis un parcours de répertoire (..%2F est ../). Son User-Agent annonce l'outil sqlmap. L'API répond 400 : la validation des entrées a rejeté les deux requêtes.
• 10.0.2.18, un poste interne, lit sa fiche 1187 puis essaie 1188, 1189, 1190 en une seconde chacune : une tentative d'IDOR par un utilisateur authentifié. Le contrôle d'accès fonctionne : l'API répond 404 sans révéler les fiches, comme la route corrigée du chapitre 3. Mais une série de 404 sur des identifiants qui se suivent est un comportement à signaler.

Analyser avec la ligne de commande

Sur un serveur Linux, quelques commandes enchaînées suffisent pour une première analyse. awk découpe chaque ligne en champs séparés par des espaces ($1 est l'adresse IP, $7 le chemin, $9 le code de statut).

# Nombre de requêtes par adresse IP, de la plus active à la moins active
awk '{print $1}' access.log | sort | uniq -c | sort -rn

   4 198.51.100.23
   4 10.0.2.18
   2 203.0.113.80
   2 10.0.2.31

# Répartition des codes de statut
awk '{print $9}' access.log | sort | uniq -c | sort -rn

   7 404
   3 200
   2 400

# Qui reçoit des 404 sur des fiches (refus d'accès déguisés) ?
awk '$9 == 404 && $7 ~ /^\/api\/fiches\// {print $1}' access.log | sort | uniq -c

   3 10.0.2.18

# Requêtes qui ressemblent à une injection SQL ou à un parcours de répertoire
grep -Ei "union|select|%27|\.\.%2f|\.\./" access.log | awk '{print $1, $7}'

203.0.113.80 /api/fiches?mois=202603%27%20UNION%20SELECT%20login,mdp_hash%20FROM%20utilisateur--%20
203.0.113.80 /api/justificatifs?fichier=..%2F..%2F..%2Fetc%2Fpasswd

Sous Windows, PowerShell offre l'équivalent avec Select-String et Group-Object (cours Scripting PowerShell et Bash). Le cours Administration Linux détaille grep, awk et les journaux du système.

Analyser les connexions avec SQL

Quand les connexions sont journalisées dans une table, SQL devient l'outil d'analyse. C'est un exercice classique de l'E7. Voici le contenu de la table journal (colonnes utiles) pour la nuit et la matinée du 12 mars 2026 :

Les adresses IP qui accumulent les échecs (seuil : 5) :

SELECT ip, COUNT(*) AS nb_echecs
FROM journal
WHERE resultat = 'echec'
GROUP BY ip
HAVING COUNT(*) >= 5
ORDER BY nb_echecs DESC;

La condition sur resultat va dans le WHERE (elle filtre des lignes), la condition sur le nombre d'échecs dans le HAVING (elle filtre des groupes). Confondre les deux est le piège classique (WHERE ou HAVING).

Distinguer la force brute du password spraying. Les deux adresses ont un nombre d'échecs comparable, mais pas le même comportement. On compte les comptes distincts visés :

SELECT ip, COUNT(DISTINCT login) AS nb_comptes, COUNT(*) AS nb_echecs
FROM journal
WHERE resultat = 'echec'
GROUP BY ip
HAVING COUNT(DISTINCT login) >= 3;

198.51.100.7 a essayé un mot de passe sur cinq comptes en vingt secondes : c'est du password spraying. 203.0.113.45 s'acharne sur un seul compte : c'est de la force brute.

Le plus grave : un succès après une série d'échecs.

SELECT date_heure, login, ip
FROM journal
WHERE resultat = 'succes'
  AND ip IN (SELECT ip FROM journal WHERE resultat = 'echec' GROUP BY ip HAVING COUNT(*) >= 5);

Après six échecs, l'attaquant a trouvé le mot de passe de mdurand à 2 h 13. Le compte est compromis : il faut le bloquer, réinitialiser le mot de passe, vérifier ce qui a été fait avec ce compte depuis 2 h 13, et se demander pourquoi six essais ont été possibles sans blocage.

Les connexions réussies hors des horaires de travail (avant 7 h ou à partir de 20 h) :

SELECT id, date_heure, login, ip
FROM journal
WHERE resultat = 'succes'
  AND (HOUR(date_heure) < 7 OR HOUR(date_heure) >= 20);

En production, ces requêtes portent sur une fenêtre glissante : WHERE date_heure >= NOW() - INTERVAL 15 MINUTE pour les échecs des quinze dernières minutes.

Du journal à l'alerte

Analyser à la main après coup ne suffit pas : il faut être prévenu pendant l'attaque. Les journaux de l'application, du serveur web, du pare-feu et de la base sont envoyés vers une plateforme de centralisation (pile ELK ou OpenSearch, Graylog, Grafana Loki) ou un SIEM (Security Information and Event Management, comme Wazuh), qui applique des règles et déclenche des alertes. Quelques règles typiques :

Des outils comme fail2ban lisent les journaux en continu et bloquent automatiquement au pare-feu les adresses qui dépassent un seuil. Les seuils s'ajustent pour éviter deux écueils : trop d'alertes (on finit par ne plus les lire) et trop peu (on rate l'attaque). Le cours Supervision présente la surveillance d'un système d'information.

Mal gérer une condition exceptionnelle (A10)

La catégorie A10:2025, Mishandling of Exceptional Conditions, est nouvelle. Elle regroupe les failles qui apparaissent quand l'application rencontre une situation inhabituelle (une erreur, une ressource indisponible, une entrée inattendue) et que le code ne l'empêche pas, ne la détecte pas ou y réagit mal. L'OWASP y range notamment l'échec « ouvert » (CWE-636), l'exposition d'informations dans les messages d'erreur et les exceptions non gérées.

Échouer ouvert. Le cas le plus grave : un contrôle de sécurité qui, en cas d'erreur, laisse passer.

// VULNÉRABLE : en cas d'erreur, l'accès est accordé
async function peutValider(utilisateur, idFiche) {
  try {
    const [lignes] = await pool.execute('SELECT id_visiteur, etat FROM fiche_frais WHERE id = ?', [idFiche]);
    return utilisateur.role === 'comptable' && lignes[0].etat === 'CL' && lignes[0].id_visiteur !== utilisateur.id;
  } catch (erreur) {
    console.error(erreur);
    return true;          // « pour ne pas bloquer les comptables si la base répond mal »
  }
}

Il suffit de provoquer une erreur (une fiche inexistante, donc lignes[0] indéfini, ou une base surchargée) pour que la validation soit accordée. La règle : en cas de doute, refuser (fail closed). Le catch renvoie false, journalise l'erreur, et la requête reçoit une réponse d'erreur.

Laisser tomber le serveur. Une exception non attrapée ou une promesse rejetée sans gestionnaire arrête un processus Node.js. Si une saisie particulière suffit à la provoquer, un attaquant la répète et rend l'API indisponible : c'est un déni de service.

Laisser un état incohérent. Une opération en plusieurs étapes (débiter, puis créditer ; changer l'état de la fiche, puis déclencher le virement) interrompue au milieu laisse des données fausses. L'OWASP recommande d'annuler complètement l'opération plutôt que de tenter de récupérer l'état partiel : c'est le rôle des transactions (COMMIT et ROLLBACK).

Bloquer des ressources. Un fichier, une connexion à la base ou un verrou ouverts avant une erreur et jamais libérés finissent par épuiser les ressources du serveur.

Révéler des informations. Une erreur de base de données affichée telle quelle donne la structure des tables, ce qui aide à préparer une injection (chapitre 4).

Gérer les erreurs proprement

Les recommandations de l'OWASP pour A10, appliquées à AppliFrais :

1. Attraper l'erreur là où elle se produit, et la traiter de façon utile : message compréhensible pour l'utilisateur, détail dans le journal, alerte si nécessaire.
2. Un gestionnaire d'erreurs global comme filet de sécurité pour tout ce qui aurait échappé.
3. Échouer en refusant, et annuler complètement une transaction interrompue.
4. Fixer des limites à tout ce qui consomme des ressources : taille des requêtes, taille des fichiers, durée des appels, nombre de requêtes par client. Aucune ressource ne doit être illimitée.
5. Centraliser la gestion des erreurs, pour qu'elle soit la même partout.

Avec Express 5, une erreur levée dans une route asynchrone est transmise automatiquement au gestionnaire d'erreurs (avec Express 4, il fallait l'attraper et appeler next(erreur)). Le gestionnaire global se déclare en dernier, avec quatre paramètres :

import crypto from 'node:crypto';

app.use(express.json({ limit: '100kb' }));     // limite la taille des corps JSON

// … les routes …

// Gestionnaire d'erreurs global : toujours en dernier
app.use((erreur, req, res, next) => {
  const reference = crypto.randomUUID();
  journal.error({ reference, route: `${req.method} ${req.originalUrl}`, erreur: erreur.message, pile: erreur.stack });
  res.status(erreur.status ?? 500).json({
    erreur: 'Une erreur est survenue',
    reference,               // l'utilisateur peut la communiquer au support, qui retrouve le détail
  });
});

L'utilisateur reçoit un message générique et une référence ; le développeur retrouve tout le détail dans le journal grâce à cette référence. Pour une opération en plusieurs étapes, la transaction garantit le « tout ou rien » :

const connexion = await pool.getConnection();
try {
  await connexion.beginTransaction();
  await connexion.execute("UPDATE fiche_frais SET etat = 'RB' WHERE id = ? AND etat = 'VA'", [idFiche]);
  await connexion.execute('INSERT INTO paiement (id_fiche, montant, date_ordre) VALUES (?, ?, NOW())', [idFiche, montant]);
  await connexion.commit();
} catch (erreur) {
  await connexion.rollback();     // rien n'est enregistré : pas d'état à moitié fait
  throw erreur;                   // le gestionnaire global journalise et répond
} finally {
  connexion.release();            // la connexion est rendue au pool dans tous les cas
}

En PHP, en production : display_errors = Off, log_errors = On, un gestionnaire global avec set_exception_handler(), et PDO en mode exception (PDO::ERRMODE_EXCEPTION) pour qu'aucune erreur de base ne passe inaperçue.

SELECT login, COUNT(*) AS nb_echecs
FROM journal
WHERE resultat = 'echec'
GROUP BY login
ORDER BY nb_echecs DESC, login;

SELECT ip, COUNT(*) AS nb_echecs
FROM journal
WHERE resultat = 'echec'
GROUP BY ip;

SELECT resultat, COUNT(*) AS nb
FROM journal
GROUP BY resultat;

SELECT id, date_heure, login, ip
FROM journal
WHERE resultat = 'succes' AND ip NOT LIKE '10.%';

async function verifierDroit(req, res, next) {
  try {
    const autorise = await serviceDroits.verifier(req.utilisateur.id, req.path);
    if (!autorise) return res.status(403).end();
  } catch (e) {
    console.log('service des droits indisponible');
  }
  next();
}

async function verifierDroit(req, res, next) {
  try {
    const autorise = await serviceDroits.verifier(req.utilisateur.id, req.path);
    if (!autorise) return res.status(403).end();
    next();
  } catch (e) {
    journal.error({ evenement: 'service_droits_indisponible', erreur: e.message });
    return res.status(503).json({ erreur: 'Service momentanément indisponible' });
  }
}

Pour aller plus loin. Le cours Journalisation et réponse à incident reprend la lecture des logs côté serveur (Lire et analyser des logs), la centralisation dans un SIEM et la conduite d'un incident de bout en bout.