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



The `connect-src` directive controls the connections a page can open under a Content Security Policy (CSP). It covers script-initiated requests rather than resource loads: `fetch()`, `XMLHttpRequest`, WebSocket, EventSource (server-sent events), `navigator.sendBeacon`, `<a ping>`, and WebTransport all check `connect-src`.

A minimal safe policy for this directive:

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

## Fallback chain [#fallback-chain]

`connect-src` falls back to [`default-src`](/en/docs/web-security/policies/content-security-policy/directives/default-src). If you do not set `connect-src`, these connections are governed by whatever `default-src` allows. If neither is present, the page can connect anywhere.

## Values [#values]

`connect-src` takes a space-separated source list combining [keyword sources](/en/docs/web-security/policies/content-security-policy/values/csp-keywords), [host sources](/en/docs/web-security/policies/content-security-policy/values/csp-host-source), and [scheme sources](/en/docs/web-security/policies/content-security-policy/values/csp-scheme-source):

| Value                      | Status  | Description                                                                               |
| -------------------------- | ------- | ----------------------------------------------------------------------------------------- |
| `'none'`                   | ✅ Good  | Blocks all script-initiated connections.                                                  |
| `'self'`                   | ✅ Good  | Connections to the page's own origin only.                                                |
| `https://api.example.com`  | ✅ Good  | A named backend host.                                                                     |
| `wss://socket.example.com` | ✅ Good  | A named secure WebSocket host, listed explicitly.                                         |
| `ws:` / `wss:`             | ❌ Risky | A bare scheme allows a socket connection to any endpoint. `ws:` also matches `wss:` URLs. |
| `https:`                   | ❌ Risky | Any HTTPS host; an injected script can exfiltrate data anywhere.                          |
| `*`                        | ❌ Risky | Open exfiltration. Never matches `data:`, `blob:`, or `filesystem:`.                      |

Nonces and hashes do not apply.

## Examples [#examples]

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

This allows API calls to your own origin and a named API host, plus a secure WebSocket to a named socket host.

## Common use [#common-use]

`connect-src` is the directive most likely to surprise you, because it covers things you do not think of as "loading a resource". Analytics beacons, error-reporting SDKs, feature-flag polling, live-chat widgets, and WebSocket connections all hit `connect-src`. If any of them break after you tighten CSP, this is usually the directive to check.

WebSocket and EventSource endpoints often need to be listed explicitly. A `wss://` socket host is not implied by an `https://` host of the same name in every browser, so list the `wss:` (or `ws:`) origin you actually connect to. The [Reporting API configuration checker](/tools/reporting-api) can help confirm a reporting endpoint is reachable once it is allowed.

## Security notes [#security-notes]

`connect-src` is one of the most security-relevant fetch directives because it is the main data-exfiltration path. An attacker who achieves script execution will try to send stolen data out with `fetch()` or a beacon. A tight `connect-src` that lists only your real backends limits where exfiltrated data can go, even if other defenses fail. Pair it with [`base-uri`](/en/docs/web-security/policies/content-security-policy/directives/base-uri) and [`form-action`](/en/docs/web-security/policies/content-security-policy/directives/form-action) to close the other common exfiltration channels.

## Known bypasses and risks [#known-bypasses-and-risks]

A permissive `connect-src *` or `connect-src https:` undoes most of the exfiltration benefit, since an injected script can then post data to any host. Note that a bare `*` does not match `data:`, `blob:`, or `filesystem:` connections, so those need explicit schemes if your app uses them. Allowlisting a host that itself proxies arbitrary destinations (an open redirect or a general-purpose proxy endpoint) effectively re-opens the channel, so keep the list to backends you control.

## Recommendation [#recommendation]

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

Scope `connect-src` to your own origin plus the named API and socket hosts your app really calls, and avoid bare schemes. Know its limit: WebRTC data channels bypass `connect-src` entirely, so even a tight list does not close that exfiltration path. The dedicated [webrtc directive](/en/docs/web-security/policies/content-security-policy/directives/webrtc) is the control designed for it.

## Reporting [#reporting]

When a connection is blocked, the browser sends a [csp-violation report](/en/docs/web-security/reporting-api/reports/csp-violation) with `connect-src` as the `effectiveDirective`, including the blocked URL. CentralCSP collects and aggregates these reports, so you can see every endpoint your pages actually talk to before you tighten the directive.

## Browser support [#browser-support]

`connect-src` is part of CSP Level 1 and is supported in every browser that implements CSP. It is stable and widely available.

## See also [#see-also]

* [Content Security Policy directives](/en/docs/web-security/policies/content-security-policy/introduction/csp-directives)
* [Connection-Allowlist](/en/docs/web-security/policies/connection-allowlist), the experimental deny-by-default egress alternative that also covers WebRTC and redirects
* [default-src](/en/docs/web-security/policies/content-security-policy/directives/default-src)
* [form-action](/en/docs/web-security/policies/content-security-policy/directives/form-action)
* [Host source values](/en/docs/web-security/policies/content-security-policy/values/csp-host-source)
* [CentralCSP CSP suite](/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/)