Crash
Le report crash vous indique qu un renderer de page a planté ou ne répond plus, 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 au préalable et l'envoie plus tard depuis un endpoint configuré, raison pour laquelle le crash reporting a besoin d'un endpoint serveur et ne peut pas être capté dans la page. Le payload est volontairement minimal pour des raisons de confidentialité.
Non-standard
Le crash reporting n'est défini dans aucune spécification actuelle et est implémenté principalement dans Chromium. Le body est intentionnellement réduit.
Quand le navigateur l'envoie
Quand le renderer plante (par exemple à court de mémoire) ou cesse de répondre. Le report est mis en file d'attente avant le crash et livré à l'endpoint de reporting par défaut (ou à un endpoint crash-reporting dédié) lors d'un chargement ou d'une session ultérieure. Il ne peut pas être observé dans la page via ReportingObserver, parce que la page a déjà disparu : l'endpoint serveur est le seul moyen de le recevoir.
Exemple de payload
{
"type": "crash",
"age": 27,
"url": "https://api-next.centralcsp.com/",
"user_agent": "Mozilla/5.0 ...",
"body": {
"reason": "oom",
"is_top_level": true,
"visibility_state": "visible"
}
}Chaque body de report crash porte ces champs à l'intérieur de l'enveloppe de report partagée.
Référence des champs
| Champ | Signification |
|---|---|
reason | La raison du plantage, par exemple oom (à court de mémoire) ou unresponsive. |
is_top_level | Si le document 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 est livré lors d'un chargement de page ou d'une session ultérieure, alors concevez votre récepteur pour accepter les crash reports de façon différée. 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 sont des problèmes de stabilité, mais un schéma récurrent est un signal : des crashs répétés à court de mémoire ou de non-réponse concentrés sur une page ou liés à un même script peuvent indiquer une condition de déni de service ou un script tiers défaillant (ou hostile).
Pièges
Les noms des champs du body sont en snake_case. Les contraintes de confidentialité gardent le body minimal, et la pile d'appels JS n'est jamais incluse en dehors de la Document-Policy spécifique 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