Connection-Allowlist
Le report connection-allowlist que Chrome envoie quand une page se connecte hors de sa Connection-Allowlist. Les deux formes de body, les champs et les pièges.
Dernière mise à jour:
Un report connection-allowlist vous indique qu'une page a tenté d'ouvrir une
connexion vers une destination que sa Connection-Allowlist
n'autorisait pas. En mode report-only, il montre ce qu'une politique bloquerait avant
que vous ne l'appliquiez. En mode application, il consigne ce que le navigateur a bloqué.
Chromium uniquement, et le body diffère de la spec
Chrome active Connection-Allowlist par défaut à partir de Chrome 152, et les navigateurs basés sur Chromium envoient ces reports. Firefox et Safari ne les envoient pas. Pour la plupart des connexions, Chrome envoie un body plus court que celui décrit par la spec. Lisez Deux formes de body avant de parser ces reports.
Quand le navigateur l'envoie
Le navigateur envoie un report quand un document ou un worker soumis à un header
Connection-Allowlist ou Connection-Allowlist-Report-Only ouvre une connexion à
laquelle l'allowlist ne correspond pas. La vérification couvre ces connexions :
- Les fetch et les sous-ressources, comme les scripts, les images, les polices, les beacons et les flux
EventSource - Les navigations, les iframes et les popups ouvertes avec
window.open() - Les hints
prefetch,preconnectetdns-prefetch - Les connexions WebSocket et WebTransport
- Les connexions WebRTC
Le navigateur n'envoie aucun report dans ces cas :
- L'URL utilise un scheme local, comme
data:oublob:. Les URL locales n'atteignent jamais le réseau. - Le header définit
webrtc=allowet la connexion est WebRTC. - Le header définit
redirects=allowet la requête a été redirigée.
Deux formes de body
Le report arrive dans l'enveloppe standard application/reports+json.
La spec prévoit quatre champs de body sur chaque report : url, connection,
allowlist et disposition. Chrome n'envoie les quatre que pour WebRTC.
Pour toutes les autres connexions, Chrome n'envoie que connection et disposition.
La page qui a ouvert la connexion est le url de l'enveloppe. Cet exemple montre un
fetch() bloqué en mode report-only :
{
"type": "connection-allowlist",
"age": 6,
"url": "https://shop.example.com/checkout",
"user_agent": "Mozilla/5.0 ... Chrome/154.0.0.0 Safari/537.36",
"body": {
"connection": "https://collect.example.net/data?token=abc",
"disposition": "report"
}
}Pour une connexion WebRTC, connection contient la chaîne webrtc, et le body ajoute
url et allowlist. Cet exemple montre un blocage en mode application :
{
"type": "connection-allowlist",
"age": 12,
"url": "https://shop.example.com/support",
"user_agent": "Mozilla/5.0 ... Chrome/154.0.0.0 Safari/537.36",
"body": {
"url": "https://shop.example.com/support",
"connection": "webrtc",
"allowlist": ["https://shop.example.com"],
"disposition": "enforce"
}
}Chromium envoie ces deux formes, construites à deux endroits : le service réseau et le processus du navigateur envoient deux champs, et le moteur de rendu en envoie quatre.
Référence des champs
Le body contient ces champs :
| Champ | Envoyé avec | Signification |
|---|---|---|
connection | Chaque report | L'URL bloquée avec son chemin et sa query, ou la chaîne webrtc |
disposition | Chaque report | enforce quand le navigateur a bloqué la connexion, report en mode report-only |
url | WebRTC uniquement | La page qui a ouvert la connexion |
allowlist | WebRTC uniquement | L'allowlist en vigueur |
Le navigateur retire le fragment et les éventuels identifiants de connection. Pour
les reports sans url dans le body, lisez la page dans le url de l'enveloppe. Dans
allowlist, le token response-origin apparaît sous la forme de l'origine de page
qu'il représente.
Comment lire le champ connection
La valeur de connection dépend du type de connexion :
| Connexion | Valeur de connection |
|---|---|
Fetch, image, script, beacon, EventSource, prefetch | L'URL complète, query conservée, fragment retiré |
| Navigation, iframe, popup | L'URL cible |
WebSocket vers wss://chat.example.net/ws | https://chat.example.net/ws |
| WebTransport | L'URL https: de la session |
preconnect ou dns-prefetch | L'origine avec un chemin /, comme https://cdn.example.net/ |
Toute requête redirigée, sous redirects=block | L'URL demandée par la page, jamais la cible de la redirection |
| WebRTC | webrtc |
Chrome envoie les URL longues en entier. Une capture d'une URL de plus de 3 000 caractères est arrivée sans troncature.
Comment le recevoir
Déclarez un endpoint avec un header Reporting-Endpoints,
puis pointez la politique vers lui avec le paramètre report-to=. Le
générateur Connection-Allowlist
transforme ces reports en une liste que vous revoyez puis déployez.
Reporting-Endpoints: connection-endpoint="https://<Endpoint-ID>.report.centralcsp.com"Connection-Allowlist-Report-Only: (response-origin "https://*.example.com"); report-to=connection-endpointCe qu'il vous apprend sur la sécurité
Un report connection-allowlist nomme une destination que votre page a tenté de
joindre et que vous n'avez jamais autorisée. C'est le signal d'une tentative
d'exfiltration, ou d'un tiers qui va frapper à une porte inattendue. C'est le même
risque supply-chain que remontent le script inventory
et le reporting de la politique de sécurité du contenu (CSP), cette fois au niveau des
sorties réseau.
Pièges
Surveillez ces différences quand vous parsez les reports :
- La page est dans l'enveloppe. Ne comptez pas sur
body.urlnibody.allowlist. Seuls les reports WebRTC les contiennent. - Les WebSockets arrivent en
https:. Le navigateur convertitws:etwss:enhttp:ethttps:avant de vérifier l'allowlist, et il reporte l'URL convertie. Un report qui nomme une URLwss:ne vient pas de Chrome. Pour savoir comment les lister, consultez Destinations WebSocket. - Votre propre origine peut apparaître. Avec les redirections bloquées, le navigateur reporte l'URL demandée par la page, pas la destination de la redirection. Un report qui nomme votre propre origine signifie en général que le navigateur a bloqué une redirection.
- Certaines connexions sont reportées deux fois. Chrome envoie deux reports identiques pour chaque navigation, iframe, popup et
preconnectbloqués. Un doublon ressemble en tout point à une seconde tentative réelle, donc ne prenez pas le nombre de reports pour un nombre exact de connexions. - N'importe qui peut envoyer un report. Un endpoint de reporting est public, donc un report peut être falsifié. Vérifiez une destination avant de l'autoriser.
Prise en charge par les navigateurs
Chrome et les autres navigateurs basés sur Chromium appliquent le header et envoient ce report à partir de la version 152, sur desktop et Android. Chrome a mené un origin trial de la version 148 à la 151. Firefox et Safari ne l'implémentent pas. La spec est un Draft Community Group Report du Web Platform Incubator Community Group (WICG), pas un standard W3C.
Voir aussi
- header Connection-Allowlist
- Connection Allowlists, un bac à sable des sorties réseau dans le navigateur
- report csp-violation
- Construire une Connection-Allowlist depuis vos reports
- Les reports Connection-Allowlist dans CentralCSP
- Le format de livraison des reports
Sources
Violation d'intégrité
Le rapport integrity-violation se déclenche quand Integrity-Policy bloque un script dépourvu de métadonnées Subresource Integrity valides.
Vue d'ensemble
Le fonctionnement de chaque politique navigateur configurable, ce contre quoi elle protège, et comment elle remonte ses rapports via la Reporting API.