# connect-src (/fr/docs/web-security/policies/content-security-policy/directives/connect-src)



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:

```http
Content-Security-Policy: connect-src 'self' https://api.example.com
```

## Chaîne de repli [#chaîne-de-repli]

`connect-src` se replie sur [`default-src`](/fr/docs/web-security/policies/content-security-policy/directives/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 [#valeurs]

`connect-src` accepte une liste de sources séparées par des espaces combinant [sources mots-clés](/fr/docs/web-security/policies/content-security-policy/values/csp-keywords), [host sources](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source) et [scheme sources](/fr/docs/web-security/policies/content-security-policy/values/csp-scheme-source):

| 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 [#exemples]

```http
Content-Security-Policy:
  default-src 'self';
  connect-src 'self' https://api.example.com wss://socket.example.com
```

Cela 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 [#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](/tools/reporting-api) peut aider à confirmer qu'un endpoint de reporting est joignable une fois autorisé.

## Notes de sécurité [#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`](/fr/docs/web-security/policies/content-security-policy/directives/base-uri) et [`form-action`](/fr/docs/web-security/policies/content-security-policy/directives/form-action) pour fermer les autres canaux d'exfiltration courants.

## Contournements et risques connus [#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 [#recommandation]

```http
Content-Security-Policy: connect-src 'self' https://api.example.com wss://socket.example.com
```

Limitez `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](/fr/docs/web-security/policies/content-security-policy/directives/webrtc) est le contrôle conçu pour cela.

## Reporting [#reporting]

Quand une connexion est bloquée, le navigateur envoie un [report csp-violation](/fr/docs/web-security/reporting-api/reports/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 [#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 [#voir-aussi]

* [Directives de la Content Security Policy](/fr/docs/web-security/policies/content-security-policy/introduction/csp-directives)
* [Connection-Allowlist](/fr/docs/web-security/policies/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](/fr/docs/web-security/policies/content-security-policy/directives/default-src)
* [form-action](/fr/docs/web-security/policies/content-security-policy/directives/form-action)
* [Valeurs host source](/fr/docs/web-security/policies/content-security-policy/values/csp-host-source)
* [Suite CSP CentralCSP](/platform/csp-builder)

## Sources [#sources]

* [MDN, CSP connect-src](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/connect-src)
* [W3C, Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
* [W3C CSP editor's draft](https://w3c.github.io/webappsec-csp/)
