CORS
Attach to:
About CORS
Cross-origin resource sharing (CORS) CORS (Cross-Origin Resource Sharing) A security mechanism that allows web pages to make requests to a different domain than the one serving the web page. Agentgateway can configure CORS headers to control cross-origin access. is a browser security mechanism which allows a server to control which origins can request and interact with resources that are hosted on a different domain. By default, web browsers only allow requests to resources that are hosted on the same domain as the web page that served the original request. Access to web pages or resources that are hosted on a different domain is restricted to prevent potential security vulnerabilities, such as cross-site request forgery (CRSF).
When CORS is enabled in a web browser and a request for a different domain comes in, the web browser checks whether this request is allowed or not. To do that, it typically sends a preflight request (HTTP OPTIONS method) to the server or service that serves the requested resource. The service returns the methods that are permitted to send the actual cross-origin request, such as GET, POST, etc. If the request to the different domain is allowed, the response includes CORS-specific headers that instruct the web browser how to make the cross-origin request. For example, the CORS headers typically include the origin that is allowed to access the resource, and the credentials or headers that must be included in the cross-origin request.
Review the following diagram to see an example CORS request flow:
sequenceDiagram
participant B as Browser (JavaScript)
participant AGW as Agentgateway Proxy
participant Backend as Backend Service<br/>(LLM / MCP / Agent)
Note over B,Backend: CORS Preflight Flow
B->>AGW: OPTIONS /api (Preflight)<br/>Origin: https://app.example.com
AGW->>AGW: Check origin against<br/>allowOrigins list
alt Origin Allowed
AGW-->>B: 200 OK<br/>access-control-allow-origin: https://app.example.com<br/>access-control-allow-methods: GET, POST, OPTIONS<br/>access-control-allow-headers: Authorization, Content-Type<br/>access-control-max-age: 86400
B->>AGW: POST /api (Actual Request)<br/>Origin: https://app.example.com<br/>Authorization: Bearer <token>
AGW->>Backend: Forward request
Backend-->>AGW: Response
AGW-->>B: Response + CORS headers
else Origin NOT Allowed
AGW-->>B: 200 OK (no CORS headers)<br/>Browser blocks the response
Note over B: Browser denies access<br/>to response data
end
Note that the preflight request is optional. Web browsers can also be configured to send the cross-origin directly. However, access to the request resource is granted only if CORS headers were returned in the response. If no headers are returned during the preflight request, the web browser denies access to the resource in the other domain.
CORS policies are typically implemented to limit access to server resources for JavaScripts that are embedded in a web page, such as:
- A JavaScript on a web page at
example.comtries to access a different domain, such asapi.com. - A JavaScript on a web page at
example.comtries to access a different subdomain, such asapi.example.com. - A JavaScript on a web page at
example.comtries to access a different port, such asexample.com:3001. - A JavaScript on a web page at
https://example.comtries to access the resources by using a different protocol, such ashttp://example.com.
Tip
Requests that violate the CORS policy will still have responses returned, but the browser will reject them. As such, usage of tools like curl with cors can be confusing, as curl does not respect CORS headers.
Example:
cors:
allowOrigins:
- "*"
allowHeaders:
- mcp-protocol-version
- content-type
allowCredentials: true
exposeHeaders:
- x-my-header
maxAge: 100s