connect-src
La directive CSP connect-src contrôle les connexions initiées par script, comme fetch, XHR, WebSocket, EventSource et Beacon.
Dernière mise à jour:
La directive connect-src contrôle les connexions qu'une page peut ouvrir sous une politique de sécurité du contenu (Content Security Policy, CSP). Elle couvre les requêtes initiées par script plutôt que les chargements de ressources: fetch(), XMLHttpRequest, WebSocket, EventSource (server-sent events), navigator.sendBeacon, <a ping> et WebTransport vérifient tous connect-src.
Une politique minimale sûre pour cette directive:
Content-Security-Policy: connect-src 'self' https://api.example.comChaîne de repli
connect-src se replie sur default-src. Si vous ne définissez pas connect-src, ces connexions sont régies par ce que default-src autorise. Si ni l'une ni l'autre n'est présente, la page peut se connecter n'importe où.
Valeurs
connect-src accepte une liste de sources séparées par des espaces combinant sources mots-clés, host sources et scheme sources:
| Valeur | Statut | Description |
|---|---|---|
'none' | ✅ Bon | Bloque toutes les connexions initiées par script. |
'self' | ✅ Bon | Connexions vers l'origine de la page uniquement. |
https://api.example.com | ✅ Bon | Un host backend nommé. |
wss://socket.example.com | ✅ Bon | Un host WebSocket sécurisé nommé, listé explicitement. |
ws: / wss: | ❌ Risqué | Un scheme nu autorise une connexion socket vers n'importe quel endpoint. ws: correspond aussi aux URL wss:. |
https: | ❌ Risqué | N'importe quel host HTTPS; un script injecté peut exfiltrer des données n'importe où. |
* | ❌ Risqué | Exfiltration ouverte. Ne correspond jamais à data:, blob: ni filesystem:. |
Les nonces et les hashes ne s'appliquent pas.
Exemples
Content-Security-Policy:
default-src 'self';
connect-src 'self' https://api.example.com wss://socket.example.comCela autorise les appels d'API vers votre propre origine et un host d'API nommé, plus un WebSocket sécurisé vers un host de socket nommé.
Usage courant
connect-src est la directive la plus susceptible de vous surprendre, parce qu'elle couvre des choses que l'on ne perçoit pas comme un "chargement de ressource". Les beacons analytics, les SDK de remontée d'erreurs, le polling de feature flags, les widgets de chat en direct et les connexions WebSocket passent tous par connect-src. Si l'un d'eux casse après un resserrement de la CSP, c'est en général la directive à vérifier.
Les endpoints WebSocket et EventSource doivent souvent être listés explicitement. Un host wss:// n'est pas impliqué par un host https:// du même nom dans tous les navigateurs, donc listez l'origine wss: (ou ws:) à laquelle vous vous connectez réellement. Le vérificateur de configuration Reporting API peut aider à confirmer qu'un endpoint de reporting est joignable une fois autorisé.
Notes de sécurité
connect-src est l'une des directives de récupération les plus importantes pour la sécurité, parce que c'est le principal chemin d'exfiltration de données. Un attaquant qui obtient une exécution de script essaiera d'envoyer les données volées avec fetch() ou un beacon. Un connect-src serré qui ne liste que vos vrais backends limite où les données exfiltrées peuvent aller, même si les autres défenses échouent. Associez-le à base-uri et form-action pour fermer les autres canaux d'exfiltration courants.
Contournements et risques connus
Un connect-src * ou connect-src https: permissif annule l'essentiel du bénéfice anti-exfiltration, puisqu'un script injecté peut alors envoyer des données vers n'importe quel host. Notez qu'un * nu ne correspond pas aux connexions data:, blob: ni filesystem:, donc celles-ci exigent des schemes explicites si votre application les utilise. Autoriser un host qui relaie lui-même vers des destinations arbitraires (une redirection ouverte ou un endpoint proxy généraliste) rouvre le canal en pratique, donc limitez la liste aux backends que vous contrôlez.
Recommandation
Content-Security-Policy: connect-src 'self' https://api.example.com wss://socket.example.comLimitez connect-src à votre propre origine plus les hosts d'API et de socket nommés que votre application appelle réellement, et évitez les schemes nus. Connaissez sa limite: les data channels WebRTC contournent entièrement connect-src, donc même une liste serrée ne ferme pas ce chemin d'exfiltration. La directive dédiée webrtc est le contrôle conçu pour cela.
Reporting
Quand une connexion est bloquée, le navigateur envoie un report csp-violation avec connect-src comme effectiveDirective, incluant l'URL bloquée. CentralCSP collecte et agrège ces reports, pour que vous voyiez chaque endpoint auquel vos pages parlent réellement avant de resserrer la directive.
Prise en charge par les navigateurs
connect-src fait partie de CSP Level 1 et est prise en charge par tous les navigateurs qui implémentent CSP. Elle est stable et largement disponible.
Voir aussi
- Directives de la Content Security Policy
- Connection-Allowlist, l'alternative expérimentale de contrôle des sorties réseau en refus par défaut, qui couvre aussi WebRTC et les redirections
- default-src
- form-action
- Valeurs host source
- Suite CSP CentralCSP