CORS

CORS is the mechanism by which a server tells a browser that it may relax the same-origin policy for a particular caller. That is the whole of it. It is not authentication, not authorisation and not a defence against anything that is not a browser — a script with a command-line HTTP client never consults it and never has to.

Status: Reference What this means
Audience: developer, both
Last verified: 2026-09-10
Product version: 6.3.2

The rule being relaxed#

The same-origin policy stops JavaScript running on one origin from reading a response from another. Origin means scheme, host and port together, so a different port is a different origin, and so is http against https. The request may still be sent — that is the part people misremember — but the response is withheld from the script.

Cross-Origin Resource Sharing is the server's way of saying it does not mind. The response carries headers naming who may read it, and the browser enforces them. Nothing about that reaches the server's own decision about whether to do the work.

What a preflight is asking#

Some cross-origin requests go straight out — a GET, or a form-style POST with an ordinary content type. Anything beyond that set is preflighted: before the real request, the browser sends an OPTIONS asking whether this method and these headers would be permitted.

OPTIONS /api/example HTTP/1.1
Origin: https://caller.example.net
Access-Control-Request-Method: PATCH
Access-Control-Request-Headers: content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://caller.example.net
Access-Control-Allow-Methods: GET, POST, PATCH
Access-Control-Allow-Headers: content-type
Access-Control-Max-Age: 600

The preflight exists to protect servers written before any of this, which assumed a cross-origin DELETE was impossible. It is a question, not a permission check — the answer is advisory to the browser and to nobody else.

Access-Control-Allow-Origin: Which origin may read the response. One value or *, never a list
Access-Control-Allow-Credentials: Whether cookies may be attached. Incompatible with *, which is a deliberate restriction rather than an oversight
Access-Control-Max-Age: How long the browser may cache the preflight answer, which is the difference between one extra round trip and one per request
Origin (on the request): What the browser says about itself. Useful to a server, and trivially forged by anything that is not a browser

The header that is not a security boundary#

Setting a permissive Access-Control-Allow-Origin does not open a server to anyone who could not already call it; it opens it to *browser scripts* on other origins. Conversely, a restrictive one protects nothing against a determined caller, because the enforcement lives in the browser the caller is not using.

Server-side Origin validation is a separate and genuine control, and the two are easily confused. The Model Context Protocol revision dated 2026-07-28 requires that a server validate the Origin header and answer 403 when it is present and invalid — that is the server refusing to act, not a browser declining to hand over a response.

Does Connect use CORS?#

Barely, and deliberately. The application at /app and the API it calls are served from the same origin, so ordinary use of Connect involves no cross-origin request at all and no CORS headers are consulted. A customer session's request is rewritten by tenantAdapt to a /api/customer/ui/… path on the same host, then checked against the customer_safe allowlist — an authorisation decision made on the server, not a browser negotiation.

The published developer artefacts — the OpenAPI description, the Arazzo workflows, the AsyncAPI document, the agent card — are static files fetched from the same site.
The application's own /openapi.json, /docs and /redoc are closed and stay closed, so there is no interactive explorer making cross-origin calls on your behalf.
For the agent-facing endpoints, the control that matters is server-side: Origin validated and refused with 403 where the specification requires it, plus authentication for anything not public.

So the honest answer is that CORS is background knowledge for reading this documentation rather than a knob a workspace configures.

Questions#

My browser console says a request was blocked by CORS. Was it refused?

Usually not. Unless it was preflighted and the preflight failed, the request was sent and the server acted on it; what was blocked was your script reading the response. That distinction matters when the request had an effect — a blocked read does not mean nothing happened.

Can I call Connect's API from a page on my own domain?

Browser-to-API calls from another origin are not the integration path this product documents. The published surfaces for building against Connect are the developer artefacts and the agent protocols, which are called from a server or an agent runtime where the same-origin policy does not apply and authentication does.

Is `Access-Control-Allow-Origin: *` dangerous?

On a public, unauthenticated resource it is ordinary and harmless. It becomes a problem on anything that answers differently depending on who is asking, because a script on any site could then read a response meant for one person. Credentials cannot be combined with the wildcard at all, which removes the worst version of that mistake.