Crash
Le report crash signale le plantage ou le blocage du renderer de page, livré une fois la page disparue.
Dernière mise à jour:
Un report crash vous indique que le processus renderer d'une page a planté ou s'est figé. Comme la page ne tourne plus, le navigateur met le report en file d'attente à l'avance et l'envoie plus tard depuis un endpoint configuré. C'est pour cette raison que le crash reporting exige un endpoint serveur et ne peut pas être capté dans la page. Le payload est volontairement minimal, par souci de confidentialité.
Non-standard
Aucune spécification actuelle ne définit le crash reporting, implémenté principalement dans Chromium. Le body est volontairement réduit.
Quand le navigateur l'envoie
Quand le renderer plante (par manque de mémoire, par exemple) ou cesse de répondre. Le navigateur met le report en file d'attente avant le crash et le livre à l'endpoint de reporting par défaut (ou à un endpoint crash-reporting dédié) lors d'un chargement ou d'une session ultérieure. ReportingObserver ne peut pas le voir passer dans la page, puisque celle-ci a déjà disparu : seul l'endpoint serveur permet de le recevoir.
Exemple de payload
{
"type": "crash",
"age": 27,
"url": "https://example.com/",
"user_agent": "Mozilla/5.0 ...",
"body": {
"reason": "oom",
"is_top_level": true,
"visibility_state": "visible"
}
}Le body d'un report crash contient ces champs, à l'intérieur de l'enveloppe de report commune.
Référence des champs
| Champ | Signification |
|---|---|
reason | La raison du plantage, par exemple oom (manque de mémoire) ou unresponsive. |
is_top_level | Si le document qui a planté était la page de premier niveau. |
visibility_state | Si la page était visible ou hidden à ce moment-là. |
stack | Une pile d'appels JS optionnelle, incluse uniquement quand reason vaut unresponsive et que Document-Policy: include-js-call-stacks-in-crash-reports est défini. |
Comment le recevoir
Déclarez un endpoint default dans Reporting-Endpoints. Le report n'arrive pas immédiatement, il attend un chargement de page ou une session ultérieure : prévoyez donc un récepteur capable d'accepter des crash reports différés. CentralCSP collecte les signaux de crash aux côtés de vos autres reports.
Ce qu'il vous apprend sur la sécurité
La plupart des crashs relèvent de la stabilité, mais leur répétition est un signal : des crashs par manque de mémoire ou des blocages qui se concentrent sur une page ou sur un même script peuvent trahir un déni de service, ou un script tiers défaillant (voire hostile).
Pièges
Les noms des champs du body sont en snake_case. Les contraintes de confidentialité maintiennent le body au minimum, et la pile d'appels JS n'apparaît jamais en dehors de la Document-Policy indiquée ci-dessus.
Prise en charge par les navigateurs
Navigateurs basés sur Chromium uniquement ; pas Baseline. Les autres moteurs n'émettent pas de crash reports.
Voir aussi
- Document-Policy
- Fonctionnement de la Reporting API
- Reports de crash et de non-réponse du navigateur
- Monitoring des crashs dans CentralCSP
- Header Reporting-Endpoints
- Le format de livraison des rapports