Utilisez l'API Reporting pour surveiller les cas de non-respect de la sécurité, les appels d'API obsolètes, etc.
Certaines erreurs ne se produisent qu'en production. Vous ne les verrez pas en local ni pendant le développement, car des utilisateurs réels, de vrais réseaux et des appareils réels changent la donne. L'API Reporting permet de détecter certaines de ces erreurs, telles que les violations de sécurité ou les appels d'API obsolètes et bientôt obsolètes sur votre site, et les transmet à un point de terminaison que vous avez spécifié.
Il vous permet de déclarer ce que vous souhaitez surveiller via des en-têtes HTTP. Il est géré par le navigateur.
La configuration de l'API Reporting vous permet d'être certain de savoir quand les utilisateurs rencontrent ce type d'erreurs et de les corriger.
Cet article explique ce que cette API peut faire et comment l'utiliser. C'est parti !
Démonstration et code
Découvrez l'API Reporting en action à partir de Chrome 96 et des versions ultérieures (Chrome bêta ou Canary, à compter d'octobre 2021).
Présentation
![Schéma résumant les étapes ci-dessous, de la création du rapport à l'accès par le développeur au rapport](https://developer.chrome.com/static/docs/capabilities/web-apis/reporting-api/image/diagram-summarizing-step-7115c265c2e02.png?authuser=6&hl=fr)
Supposons que votre site, site.example
, dispose d'une règle Content-Security-Policy et d'une règle Document-Policy. Vous ne savez pas ce que ça fait ? Ce n'est pas grave, vous serez toujours
en mesure de comprendre cet exemple.
Vous décidez de surveiller votre site pour savoir quand ces règles ne sont pas respectées, mais aussi pour garder un œil sur les API que votre codebase est susceptible d'utiliser.
Pour ce faire, configurez un en-tête Reporting-Endpoints
et mappez ces noms de points de terminaison via la directive report-to
dans vos stratégies si nécessaire.
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the `default` endpoint
Un événement imprévu se produit, et ces règles sont enfreintes pour certains de vos utilisateurs.
Exemples de non-respect des règles
index.html
<script src="script.js"></script>
<!-- CSP VIOLATION: Try to load a script that's forbidden as per the Content-Security-Policy -->
<script src="https://example.com/script.js"></script>
script.js
, chargé par index.html
// DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policy
try {
document.write('<h1>hi</h1>');
} catch (e) {
console.log(e);
}
// DEPRECATION: Call a deprecated API
const webkitStorageInfo = window.webkitStorageInfo;
Le navigateur génère un rapport sur les cas de non-respect des règles CSP, un rapport de non-respect des règles Document-Policy et un rapport d'abandon qui recensent ces problèmes.
Après un court délai (jusqu'à une minute), le navigateur envoie les rapports au point de terminaison configuré pour ce type de non-conformité. Les rapports sont envoyés hors bande par le navigateur lui-même (et non par votre serveur ou votre site).
Le ou les points de terminaison reçoivent ces rapports.
Vous pouvez désormais accéder aux rapports sur ces points de terminaison et surveiller le problème. Vous pouvez maintenant commencer à résoudre le problème qui affecte vos utilisateurs.
Exemple de rapport
{
"age": 2,
"body": {
"blockedURL": "https://site2.example/script.js",
"disposition": "enforce",
"documentURL": "https://site.example",
"effectiveDirective": "script-src-elem",
"originalPolicy": "script-src 'self'; object-src 'none'; report-to main-endpoint;",
"referrer": "https://site.example",
"sample": "",
"statusCode": 200
},
"type": "csp-violation",
"url": "https://site.example",
"user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
}
Cas d'utilisation et types de rapports
L'API Reporting peut être configurée pour vous aider à surveiller de nombreux types d'avertissements ou de problèmes intéressants qui se produisent sur votre site:
Type de rapport | Exemple de situation dans laquelle un rapport est généré |
---|---|
Non-respect de CSP (niveau 3 uniquement) | Vous avez défini un Content-Security-Policy (CSP) sur l'une de vos pages, mais celle-ci tente de charger un script non autorisé par votre CSP. |
Non-respect de la règle COOP | Vous avez défini un Cross-Origin-Opener-Policy sur une page, mais une fenêtre multi-origine tente d'interagir directement avec le document. |
Non-respect des règles COEP | Vous avez défini un élément Cross-Origin-Embedder-Policy sur une page, mais le document comprend un iFrame multi-origine qui n'a pas activé le chargement par des documents multi-origines. |
Non-respect des règles relatives aux documents | La page comporte une règle de document qui empêche l'utilisation de document.write , mais un script tente d'appeler document.write . |
Non-respect des Règles relatives aux autorisations | La page contient une règle d'autorisation qui empêche l'utilisation du micro, et un script qui demande une entrée audio. |
Avertissement d'abandon | La page utilise une API qui est ou va le devenir. Elle l'appelle directement ou via un script tiers de premier niveau. |
Intervention | La page tente d'effectuer une action que le navigateur décide de ne pas respecter, pour des raisons de sécurité, de performances ou d'expérience utilisateur. Exemple dans Chrome: la page utilise document.write sur les réseaux lents ou appelle navigator.vibrate dans une trame multi-origine avec laquelle l'utilisateur n'a pas encore interagi. |
Accident | Le navigateur plante lorsque votre site est ouvert. |
Rapports
À quoi ressemblent les rapports ?
Le navigateur envoie les rapports au point de terminaison que vous avez configuré. Il envoie des requêtes qui se présentent comme suit:
POST
Content-Type: application/reports+json
La charge utile de ces demandes est une liste de rapports.
Liste d'exemples de rapports
[
{
"age": 420,
"body": {
"columnNumber": 12,
"disposition": "enforce",
"lineNumber": 11,
"message": "Document policy violation: document-write is not allowed in this document.",
"policyId": "document-write",
"sourceFile": "https://site.example/script.js"
},
"type": "document-policy-violation",
"url": "https://site.example/",
"user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
},
{
"age": 510,
"body": {
"blockedURL": "https://site.example/img.jpg",
"destination": "image",
"disposition": "enforce",
"type": "corp"
},
"type": "coep",
"url": "https://dummy.example/",
"user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
}
]
Voici les données que vous pouvez trouver dans chacun de ces rapports:
Champ | Description |
---|---|
age |
Nombre de millisecondes entre l'horodatage du rapport et l'heure actuelle. |
body |
Données de rapport réelles, sérialisées dans une chaîne JSON. Les champs contenus dans l'body d'un rapport sont déterminés par l'type du rapport. ⚠️ Les signalements de différents types ont des corps différents.
Pour afficher le corps exact de chaque type de rapport, consultez le point de terminaison des rapports démographiques et suivez les instructions pour générer des exemples de rapports. |
type |
Un type de rapport (par exemple, csp-violation ou coep ) |
url |
Adresse du document ou du collaborateur à partir duquel le rapport a été généré. Les données sensibles, telles que le nom d'utilisateur, le mot de passe et le fragment, sont supprimées de cette URL. |
user_agent |
En-tête User-Agent de la requête à partir de laquelle le rapport a été généré. |
Rapports identifiés
Les points de terminaison de rapport qui ont la même origine que la page qui génère le rapport reçoivent les identifiants (cookies) dans les requêtes contenant les rapports.
Les identifiants peuvent fournir un contexte supplémentaire utile sur le rapport, par exemple pour déterminer si le compte d'un utilisateur donné déclenche régulièrement des erreurs ou si une certaine séquence d'actions effectuées sur d'autres pages déclenche un rapport sur cette page.
Quand et comment le navigateur envoie-t-il les rapports ?
Les rapports sont transmis hors bande à partir de votre site: le navigateur contrôle leur envoi aux points de terminaison configurés. Il n'existe également aucun moyen de contrôler à quel moment le navigateur envoie les rapports. Il les capture, les met en file d'attente et les envoie automatiquement au moment opportun.
Cela signifie que l'utilisation de l'API Reporting présente peu ou pas de problèmes de performances.
Les rapports sont envoyés avec un délai (jusqu'à une minute) afin d'augmenter vos chances d'être envoyés de manière groupée. Cela permet d'économiser la bande passante afin de respecter la connexion réseau de l'utilisateur, ce qui est particulièrement important sur mobile. Le navigateur peut également retarder la livraison s'il est occupé à traiter une tâche prioritaire, ou si l'utilisateur est sur un réseau lent et/ou encombré à ce moment-là.
Problèmes liés aux données tierces et aux données propriétaires
Les rapports générés en raison de violations ou d'abandons se produisant sur votre page seront envoyés aux points de terminaison que vous avez configurés. Cela inclut les cas de non-respect commis par les scripts tiers exécutés sur votre page.
Les cas de non-respect ou d'abandon survenus dans un iFrame multi-origine intégré à votre page ne seront pas signalés à vos points de terminaison (du moins par défaut). Un iFrame peut configurer ses propres rapports, voire les transmettre au service de création de rapports propriétaire de votre site, mais cela dépend du site intégré dans des cadres. Notez également que la plupart des rapports ne sont générés que si les règles d'une page ne sont pas respectées, et que celles de votre page sont différentes de celles de l'iFrame.
Exemple avec abandons
![Si l'en-tête Reporting-Endpoints est configuré sur votre page: une API obsolète appelée par des scripts tiers exécutés sur votre page sera signalée à votre point de terminaison. Une API obsolète appelée par un iFrame intégré à votre page ne sera pas signalée à votre point de terminaison. Un rapport d'abandon ne sera généré que si le serveur iFrame a configuré des points de terminaison de création de rapports. Il sera envoyé au point de terminaison configuré par le serveur de l'iFrame.](https://developer.chrome.com/static/docs/capabilities/web-apis/reporting-api/image/if-reporting-endpoints-h-c4facaee3ba26.png?authuser=6&hl=fr)
Prise en charge des navigateurs
Le tableau ci-dessous récapitule les navigateurs compatibles avec l'API Reporting v1, c'est-à-dire avec l'en-tête Reporting-Endpoints
. La compatibilité du navigateur avec l'API Reporting v0 (en-tête Report-To
) est identique, à l'exception d'un type de rapport: la journalisation des erreurs réseau n'est pas compatible avec la nouvelle API Reporting.
Pour en savoir plus, consultez le guide de migration.
Type de rapport | Chrome | Chrome pour iOS | Safari | Firefox | Périphérie |
---|---|---|---|---|---|
Non-respect de CSP (niveau 3 uniquement)* | ✔ Oui | ✔ Oui | ✔ Oui | ✘ Non | ✔ Oui |
Journalisation des erreurs réseau | ✘ Non | ✘ Non | ✘ Non | ✘ Non | ✘ Non |
Non-respect COOP/COEP | ✔ Oui | ✘ Non | ✔ Oui | ✘ Non | ✔ Oui |
Tous les autres types: Non-respect des règles relatives aux documents, abandon, intervention, plantage | ✔ Oui | ✘ Non | ✘ Non | ✘ Non | ✔ Oui |
Ce tableau résume uniquement la prise en charge de report-to
avec le nouvel en-tête Reporting-Endpoints
. Si vous envisagez de migrer vers Reporting-Endpoints
, consultez les conseils pour migrer les rapports CSP.
Utiliser l'API Reporting
Déterminer où envoyer les rapports
Vous avez deux possibilités :
- Envoyez des rapports à un service de collecteur de rapports existant.
- Envoyez des rapports à un collecteur de rapports que vous créez et gérez vous-même.
Option 1: Utiliser un service de collecteur de rapports existant
Voici quelques exemples de services de collecteur de rapports:
Si vous connaissez d'autres solutions, signalez-nous le problème afin de nous en informer et nous mettrons à jour ce post.
En plus du prix, tenez compte des points suivants lorsque vous sélectionnez un collecteur de rapports: 🧐
- Ce collecteur est-il compatible avec tous les types de rapports ? Par exemple, les solutions de point de terminaison de création de rapports ne sont pas toutes compatibles avec les rapports COOP/COEP.
- Savez-vous partager les URL de votre application avec un outil de collecte de rapports tiers ? Même si le navigateur supprime les informations sensibles de ces URL, elles peuvent être divulguées de cette manière. Si cela semble trop risqué pour votre application, exploitez votre propre point de terminaison de création de rapports.
Option 2: Créer et exploiter votre propre collecteur de rapports
Créer votre propre serveur qui reçoit des rapports n'est pas si simple. Pour commencer, vous pouvez dupliquer notre code récurrent léger. Elle est basée sur Express, et peut recevoir et afficher des rapports.
Accédez au collecteur de rapports récurrent.
Cliquez sur Remix to Edit (Remixer pour modifier) pour rendre le projet modifiable.
Vous avez maintenant votre clone. Vous pouvez le personnaliser en fonction de vos besoins.
Si vous n'utilisez pas le code standard et créez entièrement votre propre serveur:
- Recherchez les requêtes
POST
avec unContent-Type
défini surapplication/reports+json
pour reconnaître les requêtes de rapports envoyées par le navigateur à votre point de terminaison. - Si votre point de terminaison se trouve sur une origine différente de celle de votre site, assurez-vous qu'il accepte les requêtes CORS préliminaires.
Option 3: combiner les options 1 et 2
Vous pouvez laisser un fournisseur spécifique s'occuper de certains types de rapports, tout en disposant d'une solution interne pour d'autres.
Dans ce cas, définissez plusieurs points de terminaison comme suit:
Reporting-Endpoints: endpoint-1="https://reports-collector.example", endpoint-2="https://my-custom-endpoint.example"
Configurer l'en-tête Reporting-Endpoints
Définissez un en-tête de réponse Reporting-Endpoints
. Sa valeur doit correspondre à une ou plusieurs paires clé/valeur séparées par une virgule:
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Si vous passez de l'ancienne API Reporting à la nouvelle, il peut être judicieux de définir à la fois Reporting-Endpoints
et Report-To
. Pour en savoir plus, consultez le guide de migration. En particulier, si vous utilisez la création de rapports pour les cas de non-respect des règles Content-Security-Policy
via la directive report-uri
uniquement, consultez la procédure de migration pour la création de rapports CSP.
Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: ...
Clés (noms des points de terminaison)
Chaque clé peut être le nom de votre choix, comme main-endpoint
ou endpoint-1
.
Vous pouvez décider de définir différents points de terminaison nommés pour différents types de rapports (par exemple, my-coop-endpoint
ou my-csp-endpoint
). Vous pouvez ainsi acheminer les rapports vers différents points de terminaison en fonction de leur type.
Si vous souhaitez recevoir des rapports sur les interventions, les abandons et/ou les plantages, définissez un point de terminaison nommé default
.
Si l'en-tête Reporting-Endpoints
ne définit aucun point de terminaison default
, les rapports de ce type ne seront pas envoyés. Toutefois, ils le seront.
Valeurs (URL)
Chaque valeur correspond à l'URL de votre choix, vers laquelle les rapports seront envoyés. L'URL à définir ici dépend de ce que vous avez choisi à l'étape 1.
Une URL de point de terminaison:
- Doit commencer par une barre oblique (
/
). Les chemins relatifs ne sont pas acceptés. - Peut être multi-origine, mais dans ce cas, les identifiants ne sont pas envoyés avec les rapports.
Exemples
Reporting-Endpoints: my-coop-endpoint="https://reports.example/coop", my-csp-endpoint="https://reports.example/csp", default="https://reports.example/default"
Vous pouvez ensuite utiliser chaque point de terminaison nommé dans la règle appropriée ou utiliser un seul point de terminaison pour toutes les règles.
Où définir l'en-tête ?
Dans la nouvelle API Reporting, celle présentée dans cet article, les rapports sont limités à documents. Cela signifie que pour une origine donnée, différents documents, tels que site.example/page1
et site.example/page2
, peuvent envoyer des rapports à différents points de terminaison.
Pour recevoir des rapports sur les violations ou les abandons survenant sur n'importe quelle page de votre site, définissez l'en-tête en tant que middleware de toutes les réponses.
Voici un exemple avec Express:
const REPORTING_ENDPOINT_BASE = 'https://report.example';
const REPORTING_ENDPOINT_MAIN = `${REPORTING_ENDPOINT_BASE}/main`;
const REPORTING_ENDPOINT_DEFAULT = `${REPORTING_ENDPOINT_BASE}/default`;
app.use(function (request, response, next) {
// Set up the Reporting API
response.set(
'Reporting-Endpoints',
`main-endpoint="${REPORTING_ENDPOINT_MAIN}", default="${REPORTING_ENDPOINT_DEFAULT}"`,
);
next();
});
Modifier vos règles
Maintenant que l'en-tête Reporting-Endpoints
est configuré, ajoutez une directive report-to
à chaque en-tête de règle pour lequel vous souhaitez recevoir des rapports de non-respect des règles. La valeur de report-to
doit correspondre à l'un des points de terminaison nommés que vous avez configurés.
Vous pouvez utiliser un point de terminaison multiple pour plusieurs règles, ou utiliser différents points de terminaison pour toutes les stratégies.
report-to
n'est pas nécessaire pour les rapports d'abandon, d'intervention et de crash. Ces rapports ne sont liés à aucune règle. Ils sont générés tant qu'un point de terminaison default
est configuré et envoyés à ce point de terminaison default
.
Exemple
# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0;report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the default endpoint
Exemple de code
Pour voir tout cela en contexte, vous trouverez ci-dessous un exemple de serveur de nœuds qui utilise Express et rassemble tous les éléments abordés dans cet article. Il explique comment configurer la création de rapports pour différents types de rapports et affiche les résultats.
Déboguer la configuration de vos rapports
Générer intentionnellement des rapports
Lors de la configuration de l'API Reporting, vous devrez probablement enfreindre intentionnellement vos règles afin de vérifier si les rapports sont générés et envoyés comme prévu. Pour voir un exemple de code qui enfreint les règles et entraîne d'autres comportements indésirables qui génèrent des rapports de tous types, consultez la démonstration.
Gagner du temps
L'envoi des rapports peut être retardé d'environ une minute, ce qui représente une longue durée de débogage. Idéalement, lors du débogage dans Chrome, vous pouvez utiliser l'indicateur --short-reporting-delay
pour recevoir des rapports dès qu'ils sont générés.
Exécutez la commande suivante dans votre terminal pour activer cette option:
YOUR_PATH/TO/EXECUTABLE/Chrome --short-reporting-delay
Utiliser les outils de développement
Dans Chrome, utilisez les outils de développement pour consulter les rapports qui ont été envoyés ou qui le seront.
Depuis octobre 2021, cette fonctionnalité est expérimentale. Pour l'utiliser, procédez comme suit:
- Utilisez Chrome 96 ou une version ultérieure (vérifiez ce point en saisissant
chrome://version
dans votre navigateur) - Saisissez ou collez
chrome://flags/#enable-experimental-web-platform-features
dans la barre d'adresse de Chrome. - Cliquez sur Activé.
- Redémarrez le navigateur.
- Accédez aux Outils pour les développeurs Chrome.
- Dans les outils pour les développeurs Chrome, ouvrez les paramètres. Sous "Tests", cliquez sur Activer le panneau "API Reporting" dans le panneau "Application".
- Actualisez les outils de développement.
- Actualisez la page. Les rapports générés par la page dans laquelle les outils de développement sont ouverts sont répertoriés dans le panneau Application des outils pour les développeurs Chrome, sous API Reporting.
![Capture d'écran des outils de développement affichant les rapports](https://developer.chrome.com/static/docs/capabilities/web-apis/reporting-api/image/screenshot-devtools-list-adb1aaa437b6b.png?authuser=6&hl=fr)
État du rapport
La colonne État vous indique si un rapport a bien été envoyé.
État | Description |
---|---|
Success |
Le navigateur a envoyé le rapport, et le point de terminaison a répondu avec un code de réussite (200 ou un autre code de réponse de réussite, 2xx ). |
Pending |
Le navigateur tente actuellement d'envoyer le rapport. |
Queued |
Le rapport a été généré, et le navigateur ne tente actuellement pas de l'envoyer. Un rapport apparaît sous la forme Queued dans l'un de ces deux cas :
|
MarkedForRemoval |
Après un certain temps (Queued ), le navigateur a cessé de tenter d'envoyer le rapport et le supprimera bientôt de la liste des rapports à envoyer. |
Les rapports sont supprimés au bout d'un certain temps, qu'ils aient été envoyés correctement ou non.
Dépannage
Les rapports ne sont-ils pas générés ou envoyés à votre point de terminaison comme prévu ? Voici quelques conseils pour résoudre ce problème.
Les rapports ne sont pas générés
Les rapports qui s'affichent dans les outils de développement ont été correctement générés. Si le rapport attendu ne figure pas dans cette liste:
- Vérifiez
report-to
dans vos règles. Dans le cas contraire, aucun rapport ne sera généré. Pour résoudre ce problème, accédez à Modifier vos règles. Pour résoudre ce problème, vous pouvez également consulter la console DevTools dans Chrome. Si une erreur s'affiche dans la console pour le cas de non-respect attendu, cela signifie que votre règle est probablement correctement configurée. - N'oubliez pas que seuls les rapports générés pour le document dans lequel les outils de développement sont ouverts s'affichent dans cette liste. Par exemple, si votre site
site1.example
intègre un iFramesite2.example
qui enfreint une règle et génère donc un rapport, celui-ci ne s'affiche dans les outils de développement que si vous ouvrez l'iFrame dans sa propre fenêtre et que vous ouvrez les outils de développement de cette fenêtre.
Les rapports sont générés, mais ne sont pas envoyés ou ne sont pas reçus
Que faire si un rapport s'affiche dans les outils de développement, mais que votre point de terminaison ne le reçoit pas ?
- Veillez à utiliser de courts délais. Un rapport n'a peut-être pas encore été envoyé.
Vérifiez la configuration de votre en-tête
Reporting-Endpoints
. En cas de problème, un rapport généré correctement ne sera pas envoyé. Dans les outils de développement, l'état du rapport resteQueued
(il peut passer àPending
, puis rapidement àQueued
lorsqu'une tentative de distribution est effectuée). Voici quelques erreurs courantes qui peuvent être à l'origine de ce problème:Le point de terminaison est utilisé, mais pas configuré. Exemple :
Document-Policy: document-write=?0;report-to=endpoint-1; Reporting-Endpoints: default="https://reports.example/default"
Les rapports sur les cas de non-respect des règles relatives aux documents doivent être envoyés à endpoint-1
, mais ce nom de point de terminaison n'est pas configuré dans Reporting-Endpoints
.
Le point de terminaison
default
est manquant. Certains types de rapports, tels que les rapports d'abandon et d'intervention, ne seront envoyés qu'au point de terminaison nommédefault
. Pour en savoir plus, consultez la section Configurer l'en-tête Reporting-Endpoints.Recherchez les problèmes dans la syntaxe des en-têtes de règle, tels que des guillemets manquants. En savoir plus
Vérifiez que votre point de terminaison peut gérer les requêtes entrantes.
Assurez-vous que votre point de terminaison est compatible avec les requêtes CORS préliminaires. Dans le cas contraire, il ne peut pas recevoir de rapports.
Testez le comportement de votre point de terminaison. Pour ce faire, au lieu de générer des rapports manuellement, vous pouvez émuler le navigateur en envoyant à votre point de terminaison des requêtes qui ressemblent à ce que le navigateur enverra. Exécutez la commande suivante :
curl --header "Content-Type: application/reports+json" \ --request POST \ --data '[{"age":420,"body":{"columnNumber":12,"disposition":"enforce","lineNumber":11,"message":"Document policy violation: document-write is not allowed in this document.","policyId":"document-write","sourceFile":"https://dummy.example/script.js"},"type":"document-policy-violation","url":"https://dummy.example/","user_agent":"xxx"},{"age":510,"body":{"blockedURL":"https://dummy.example/img.jpg","destination":"image","disposition":"enforce","type":"corp"},"type":"coep","url":"https://dummy.example/","user_agent":"xxx"}]' \ YOUR_ENDPOINT
Votre point de terminaison doit répondre par un code de réussite (
200
ou un autre code de réponse de réussite2xx
). Si ce n'est pas le cas, il y a un problème avec sa configuration.
Mécanismes de signalement associés
Rapport uniquement
Les en-têtes de règle -Report-Only
et Reporting-Endpoints
fonctionnent ensemble.
Les points de terminaison configurés dans Reporting-Endpoints
et spécifiés dans le champ report-to
de Content-Security-Policy
, Cross-Origin-Embedder-Policy
et Cross-Origin-Opener-Policy
recevront des rapports en cas d'infraction à ces règles.
Les points de terminaison configurés dans Reporting-Endpoints
peuvent également être spécifiés dans le champ report-to
de Content-Security-Policy-Report-Only
, Cross-Origin-Embedder-Policy-Report-Only
et Cross-Origin-Opener-Policy-Report-Only
.
Ils reçoivent également des rapports en cas de non-respect de ces règles.
Bien que les rapports soient envoyés dans les deux cas, les en-têtes -Report-Only
n'appliquent pas les règles: rien n'est bloqué ni bloqué, mais vous recevez des rapports sur les éléments qui auraient été non fonctionnels ou bloqués.
ReportingObserver
L'API JavaScript ReportingObserver
peut vous aider à observer les avertissements côté client.
ReportingObserver
et l'en-tête Reporting-Endpoints
génèrent des rapports identiques, mais permettant des cas d'utilisation légèrement différents.
Utilisez ReportingObserver
si:
- Vous souhaitez uniquement surveiller les abandons et/ou les interventions du navigateur.
ReportingObserver
affiche des avertissements côté client tels que les abandons et les interventions du navigateur, mais contrairement àReporting-Endpoints
, il ne capture aucun autre type de rapport tel que les cas de non-respect des règles CSP ou COOP/COEP. - Vous devez réagir à ces cas de non-respect en temps réel.
ReportingObserver
permet d'associer un rappel à un événement de non-respect. - Vous souhaitez joindre des informations supplémentaires à un rapport pour faciliter le débogage, via le rappel personnalisé.
Une autre différence est que ReportingObserver
n'est configuré que côté client : vous pouvez l'utiliser même si vous n'avez aucun contrôle sur les en-têtes côté serveur et que vous ne pouvez pas définir Reporting-Endpoints
.
Complément d'informations
- Guide de migration de la version 0 à la version 1 de l'API Reporting
- ReportingObserver
- Spécification: ancienne API Reporting (v0)
- Spécification: nouvelle API Reporting (v1)
Image héros de Nine Koepfer / @enka80 sur Unsplash, modifiée. Un grand merci à Ian Clelland, Eiji Kitamura et Milica Mihajlija pour leurs avis et leurs suggestions concernant cet article.