Network Error Logging (NEL), signaler les échecs réseau

NEL demande au navigateur de signaler les échecs de requêtes au niveau réseau, DNS, TLS, connexion et erreurs HTTP, vers un endpoint que vous contrôlez.

Network Error Logging (NEL) demande au navigateur de collecter le résultat des requêtes réseau, échecs DNS, erreurs TLS et de connexion, resets et erreurs HTTP, et de les signaler à un endpoint serveur. Il donne aux opérateurs une visibilité sur les échecs qui n'atteignent jamais leurs propres logs, parce que la requête a échoué avant d'arriver. NEL est de l'observabilité, pas de l'application de règles.

Expérimental, et repose sur le header hérité

NEL est limité à Chromium : Mozilla a pris une position de standardisation négative pour des raisons de vie privée et Safari ne l'a jamais livré. C'est aussi le seul mécanisme qui exige encore le header déprécié Report-To ; Reporting-Endpoints ne livre pas NEL. Chrome a annoncé un mécanisme successeur, mais rien n'est livré et aucune date de retrait n'existe, donc NEL est expérimental, pas déprécié.

L'activer demande les deux headers ensemble, la définition du groupe et la politique :

Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}

NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true,"success_fraction":0.0,"failure_fraction":1.0}

Comment fonctionne NEL

Le header NEL est un objet JSON qui nomme un groupe Report-To et règle l'échantillonnage. Le navigateur signale ensuite le résultat des requêtes vers votre origine à l'endpoint de ce groupe, aux taux que vous configurez. Il faut deux headers qui travaillent ensemble : NEL active la journalisation et pointe vers un groupe, et Report-To définit où ce groupe envoie.

Comment configurer NEL

Champ	Statut	Signification
`report_to`	✅ Bon	Requis. Le nom du groupe `Report-To` qui reçoit les rapports.
`max_age`	✅ Bon	Durée en secondes pendant laquelle le navigateur retient la politique ; `0` l'efface. Par exemple `2592000` fait 30 jours.
`include_subdomains`	✅ Bon	Applique aussi la politique aux sous-domaines. Défaut `false`.
`success_fraction`	🧪 Expérimental	Fraction des succès à signaler (0.0 à 1.0, défaut 0.0). Gardez-la petite, par exemple `0.01` sur un site à fort trafic.
`failure_fraction`	✅ Bon	Fraction des échecs à signaler (0.0 à 1.0, défaut 1.0).

Mode Report-Only

NEL n'a pas de header Report-Only ; c'est un mécanisme de reporting par nature, puisqu'il ne bloque jamais rien. Vous réglez le volume avec les deux fractions à la place : signalez les échecs à 1.0 et les succès à 0 ou à un petit échantillon.

Ce contre quoi il protège

NEL relève de l'observabilité plutôt que d'un contrôle applicatif, mais il fait remonter des problèmes que votre propre monitoring ne peut pas voir : interception TLS ou échecs de certificat, problèmes DNS chez un résolveur donné, et échecs de connectivité, autant de signaux de disponibilité ou d'intégrité.

Configurations non sûres à éviter

Les endpoints doivent être en HTTPS. Une success_fraction élevée peut générer de gros volumes de rapports ; échantillonnez prudemment.

Signalez les échecs en totalité et les succès avec parcimonie ; un site chargé qui échantillonne les succès à un taux significatif inonde l'endpoint de trafic de routine.

Contournements et limites connus

Limité à Chromium, lié au header hérité Report-To (pas Reporting-Endpoints), et HTTPS uniquement. Firefox et Safari ne l'implémentent pas, et Mozilla a pris une position de standardisation négative en invoquant la vie privée.

Risques

Échantillonner les succès à une fraction élevée est coûteux et bruyant, et un max_age long fait persister la politique longtemps chez les clients, choisissez donc les deux délibérément.

Recommandation

Report-To: {"group":"nel-group","max_age":2592000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}

NEL: {"report_to":"nel-group","max_age":2592000,"success_fraction":0.01,"failure_fraction":1.0}

Signalez chaque échec (failure_fraction 1.0, le défaut) et un petit échantillon de succès comme référence, avec un max_age de 30 jours, livrés via le header hérité Report-To puisque rien d'autre ne transporte NEL. Traitez le résultat comme de la télémétrie Chromium uniquement : il couvre les utilisateurs de Chrome, Edge et Opera, pas toute votre audience.

Reporting

La valeur report_to nomme un groupe dans le header Report-To, et le navigateur émet le rapport network-error vers l'endpoint de ce groupe. CentralCSP collecte le flux NEL aux côtés de vos autres rapports.

Prise en charge par les navigateurs

Navigateurs basés sur Chromium uniquement (Chrome, Edge, Opera). Mozilla a pris une position de standardisation négative pour des raisons de vie privée et Safari ne l'a jamais livré. Chrome a annoncé un mécanisme successeur, mais rien n'est livré et aucune date de retrait n'existe, traitez donc NEL comme expérimental et limité à Chromium plutôt que déprécié.

FAQ

Qu'est-ce que Network Error Logging ?

Network Error Logging (NEL) demande au navigateur de collecter le résultat des requêtes réseau, donc les échecs DNS, les erreurs TLS et de connexion, les resets et les erreurs HTTP, et de les signaler à un endpoint que vous contrôlez. Il donne aux opérateurs une visibilité sur les échecs qui n'atteignent jamais leurs propres logs, parce que la requête a échoué avant d'arriver. NEL est de l'observabilité, pas de l'application de règles.

NEL présente-t-il un risque pour la vie privée ?

Il signale les échecs réseau à l'origine, et Mozilla a pris une position de standardisation négative pour des raisons de vie privée, ce qui explique en partie pourquoi Firefox et Safari ne l'ont jamais livré. Gardez un échantillonnage prudent : signalez les échecs en totalité et les succès à une petite fraction ou à zéro, et réglez max_age délibérément puisque la politique persiste chez les clients.

Network Error Logging