# Native CORS support on GKE Gateway: Offloading cross-origin policy management to infrastructure > Source: > Published: 2026-08-30 19:09:03+00:00 Web browsers enforce the Same-Origin Policy by default to protect users from malicious scripts trying to read data across distinct origins. However, modern application architectures almost always require cross-origin communication. Single-page applications, mobile clients, and embedded web components regularly fetch data and stream AI model inferences across separate domains, subdomains, and ports. To allow these interactions safely, applications must implement Cross-Origin Resource Sharing (CORS). For years, teams running Kubernetes workloads on Ingress-Nginx handled this using annotations like `nginx.ingress.kubernetes.io/enable-cors` . When migrating to the Kubernetes Gateway API and GKE Gateway, the lack of native CORS support was a frequent operational pain point, making it one of the most requested missing capabilities. The GKE team addressed this gap with the Preview release of [native CORS support for GKE Gateway and Inference Gateway](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/deploying-gateways#configure-cors). In this article, I will break down how the new CORS filter works, why moving cross-origin policy management to the load balancer matters, and the operational nuances you need to consider. Implementing CORS inside individual backend applications introduces architectural friction across three main areas: `OPTIONS` calls. Routing these preflight requests to backend containers wastes application memory, CPU cycles, and network bandwidth on pure protocol negotiation.By shifting CORS processing to GKE Gateway, Google Cloud Load Balancing terminates `OPTIONS` preflight requests directly at the network edge and injects required response headers (`Access-Control-Allow-Origin` , `Access-Control-Allow-Methods` , and `Access-Control-Allow-Headers` ). Your backend applications only receive validated application requests, removing boilerplate code and reducing compute overhead. GKE Gateway implements CORS support directly through the open-source Gateway API specification. You define policies declaratively using a `CORS` filter within the `rules` section of an `HTTPRoute` manifest. Here is an example configuring a CORS policy on an API route: ``` apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: api-cors-route namespace: production spec: parentRefs: - name: external-gateway rules: - matches: - path: type: PathPrefix value: /api backendRefs: - name: api-service port: 8080 filters: - type: CORS cors: allowOrigins: - "https://app.example.com" - "https://*.partner-domain.com" allowMethods: - GET - POST - PUT - DELETE allowHeaders: - Authorization - Content-Type - X-Requested-With exposeHeaders: - X-Request-ID allowCredentials: true maxAge: 3600 ``` The `cors` configuration block gives you granular control over the negotiation parameters: `allowOrigins` `https://app.example.com` ), wildcard patterns (`https://*.partner-domain.com` ), or a catch-all wildcard (`*` ).`allowMethods` `*` to allow all methods.`allowHeaders` `exposeHeaders` `allowCredentials` `Access-Control-Allow-Credentials` header to `true` or `false` , dictating whether browsers can share responses with requests carrying cookies or authentication headers.`maxAge` `OPTIONS` traffic.When designing your CORS policies on GKE Gateway, pay careful attention to the interaction between `allowOrigins` and `allowCredentials` . Under standard browser security rules, browsers block responses to credentialed requests if `Access-Control-Allow-Origin` is set to a literal wildcard (`*` ). However, when you configure wildcard patterns or a wildcard in `allowOrigins` in GKE Gateway, the controller dynamically matches and reflects the incoming request origin rather than returning a literal asterisk. Because the browser sees an explicit origin returned alongside `allowCredentials: true` , it permits the response. If you configure `allowOrigins: ["*"]` with `allowCredentials: true` , any arbitrary website can potentially read authenticated user responses. For authenticated APIs, always define explicit domain lists rather than catch-all wildcards. This Preview release supports single-cluster GKE Gateway deployments across three primary GatewayClasses: `gke-l7-rilb` `gke-l7-regional-external-managed` `gke-l7-global-external-managed` It also supports AI inference workloads exposed via Inference Gateway, allowing frontend chat interfaces or client SDKs to query served models directly across origins. Before implementing this in production, keep the following technical limits in mind: `gke-l7-gmc-*` ) do not currently support the CORS filter.`CORS` filter and a `RequestRedirect` filter within the same route rule.`gke-l7-global-external-managed` , there is a limit of one regular expression per Gateway listener, and combining wildcard origins with `PathPrefix` matches is not supported. For regional external and regional internal GatewayClasses, you can use up to five regular expressions per hostname. Note that exact origins and catch-all `*` entries do not count against these regex quotas.Native CORS support in GKE Gateway eliminates one of the biggest functional gaps for organizations migrating workloads from legacy Ingress controllers to the Kubernetes Gateway API. By managing cross-origin policies declaratively at the routing layer, platform teams can simplify application code and centralize security posture across all services. To learn more and begin testing CORS in your clusters, check out the official [GKE Gateway CORS documentation](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/deploying-gateways#configure-cors) and the upstream [Gateway API CORS User Guide](https://gateway-api.sigs.k8s.io/guides/user-guides/http-cors/).