Le format de livraison des reports
L'enveloppe application/reports+json que le navigateur envoie en POST, et en quoi elle diffère de l'ancien format application/csp-report.
Dernière mise à jour:
Lorsque le navigateur livre des reports, il envoie un POST HTTP avec
Content-Type: application/reports+json et un tableau JSON d'objets report. Chaque
report partage la même enveloppe externe ; seul le body change selon le type. Cette
page est la référence pour cette enveloppe, et pour l'ancien format à objet unique que
report-uri utilise encore.
La requête
Les reports arrivent sous forme d'un POST dont le corps est un tableau JSON, pas
un objet unique, même lorsqu'il n'y a qu'un seul report. Une seule livraison peut
regrouper plusieurs reports ensemble, et ils ne sont pas forcément du même type : une
violation CSP et une dépréciation peuvent partager un même POST si elles sont mises
en file pour le même endpoint. Votre récepteur doit parcourir le tableau et se
brancher sur le type de chaque entrée.
Les champs de l'enveloppe
Chaque entrée du tableau possède les cinq mêmes champs de premier niveau. Seul body
diffère d'un type de report à l'autre.
| Champ | Signification |
|---|---|
type | La catégorie du report, par exemple csp-violation, deprecation, network-error. |
url | Le document d'où provient le report, dépouillé de ses identifiants et de son fragment. |
user_agent | La chaîne User-Agent de la page qui a généré le report. |
age | Les millisecondes entre la génération du report et son envoi, afin de corriger le délai de batching et le décalage d'horloge. |
body | Le payload spécifique au type (les champs documentés sur chaque page de report). |
[
{
"type": "csp-violation",
"age": 53,
"url": "https://api-next.centralcsp.com/",
"user_agent": "Mozilla/5.0 ...",
"body": {
"documentURL": "https://api-next.centralcsp.com/",
"blockedURL": "https://evil.example/script.js",
"effectiveDirective": "script-src-elem",
"disposition": "enforce",
"statusCode": 200
}
}
]Le format moderne face à l'ancien format csp-report
La Reporting API utilise des champs de body en camelCase (documentURL, blockedURL) ; l'ancien format report-uri utilise un objet unique enveloppé dans csp-report avec des champs en kebab-case (document-uri, blocked-uri) et Content-Type: application/csp-report. Un endpoint qui accepte les deux doit se brancher sur le Content-Type.
L'ancien format est antérieur à la Reporting API et est spécifique à CSP. C'est un
objet unique, pas un tableau, il n'a pas d'enveloppe (pas de type, age ni
user_agent), et ses noms de champ sont en kebab-case :
{
"csp-report": {
"document-uri": "https://api-next.centralcsp.com/",
"blocked-uri": "https://evil.example/script.js",
"effective-directive": "script-src-elem",
"original-policy": "default-src 'self'; report-uri /csp-reports",
"disposition": "enforce",
"status-code": 200
}
}Donc un récepteur qui prend en charge les deux lit le Content-Type :
application/reports+json désigne le tableau moderne, application/csp-report
désigne l'objet ancien. La page du report csp-violation
documente les deux formes champ par champ.
Voir aussi
- report csp-violation
- Comment fonctionne la Reporting API
- header Reporting-Endpoints
- Où vont les reports du navigateur et comment les recevoir
Sources
Comment fonctionne la Reporting API
Comment le navigateur met en file d'attente, regroupe et livre les reports hors bande vers l'endpoint que vous déclarez.
ReportingObserver
ReportingObserver est une API JavaScript qui laisse une page lire ses propres reports en interne, y compris les reports mis en tampon avant son exécution.