Enforce client-site access controls with cross-origin resource sharing (CORS).

About CORS link

Cross-Origin Resource Sharing (CORS) is a security feature that is implemented by web browsers and that controls how web pages in one domain 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.

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.com tries to access a different domain, such as api.com.
• A JavaScript on a web page at example.com tries to access a different subdomain, such as api.example.com.
• A JavaScript on a web page at example.com tries to access a different port, such as example.com:3001.
• A JavaScript on a web page at https://example.com tries to access the resources by using a different protocol, such as http://example.com.

Before you begin link

1. Follow the Get started guide to install Solo Enterprise for kgateway.

2. Follow the Sample app guide to create a gateway proxy with an HTTP listener and deploy the httpbin sample app.

3. Get the external address of the gateway and save it in an environment variable.

     export INGRESS_GW_ADDRESS=$(kubectl get svc -n kgateway-system http -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
   echo $INGRESS_GW_ADDRESS  
     

     kubectl port-forward deployment/http -n kgateway-system 8080:8080
     

4. Important: Install the experimental channel of the Kubernetes Gateway API to use this feature.

     kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/experimental-install.yaml
     

Set up CORS policies link

Create a CORS policy for the httpbin app in an HTTPRoute or EnterpriseKgatewayTrafficPolicy.

CORS in HTTPRoute link

Create an HTTPRoute resource for the httpbin app that applies a CORS filter. The following example allows requests from the https://example.com/ origin.

  kubectl apply -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-cors
  namespace: httpbin
spec:
  parentRefs:
    - name: http
      namespace: kgateway-system
  hostnames:
    - cors.example
  rules:
    - filters:
        - type: CORS
          cors:
            allowCredentials: true
            allowHeaders:
              - Origin               
            allowMethods:
              - GET
              - POST
              - OPTIONS               
            allowOrigins:
              - "https://example.com"
            exposeHeaders:
            - Origin
            - X-HTTPRoute-Header
            maxAge: 86400
      backendRefs:
        - name: httpbin
          port: 8000
EOF
  

CORS in EnterpriseKgatewayTrafficPolicy link

1. Create a EnterpriseKgatewayTrafficPolicy resource for the httpbin app that applies a CORS filter. The following example allows requests from the https://example.com/ origin.

     kubectl apply -f- <<EOF
   apiVersion: enterprisekgateway.solo.io/v1alpha1
   kind: EnterpriseKgatewayTrafficPolicy
   metadata:
     name: httpbin-cors
     namespace: httpbin
   spec:
     cors:
       allowCredentials: true
       allowHeaders:
         - "Origin"
         - "Authorization"
         - "Content-Type"             
       allowMethods:
         - "GET"
         - "POST"
         - "OPTIONS"               
       allowOrigins:
         - "https://example.com"
       exposeHeaders:
       - "Origin"
       - "X-TrafficPolicy-Header"
       maxAge: 86400
   EOF
     

2. Attach the EnterpriseKgatewayTrafficPolicy to a route or Gateway. The following example creates an HTTPRoute for the httpbin app that has the EnterpriseKgatewayTrafficPolicy attached via the extensionRef filter. For more information about attachment and merging rules, see the EnterpriseKgatewayTrafficPolicy concept docs.

     kubectl apply -f- <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: httpbin-cors
     namespace: httpbin
   spec:
     parentRefs:
       - name: http
         namespace: kgateway-system
     hostnames:
       - cors.example
     rules:
       - filters:
           - type: ExtensionRef
             extensionRef:
               group: enterprisekgateway.solo.io
               kind: EnterpriseKgatewayTrafficPolicy
               name: httpbin-cors
         backendRefs:
           - name: httpbin
             port: 8000
   EOF
     

Test CORS policies link

Now that you have CORS policies applied via an HTTPRoute or EnterpriseKgatewayTrafficPolicy, you can test the policies.

1. Send a request to the httpbin app on the cors.example domain and use https://example.com/ as the origin. Verify that your request succeeds and that you get back the configured CORS headers.

     curl -I -X OPTIONS http://$INGRESS_GW_ADDRESS:8080/get -H "host: cors.example:8080" \
    -H "Origin: https://example.com/" \
    -H "Access-Control-Request-Method: POST" \
    -H "Access-Control-Request-Headers: Origin"
     

     curl -I -X OPTIONS localhost:8080/headers -H "host: cors.example:8080" \
    -H "Origin: https://example.com/" \
    -H "Access-Control-Request-Method: POST" \
    -H "Access-Control-Request-Headers: Origin"
     

   Example output: Notice that the `access-control-*` values reflect your CORS policy and change depending on the resources that you created. * If you created an HTTPRoute with a CORS filter, you see the `Origin` and `X-HTTPRoute-Header` headers. * If you created a TrafficPolicy with a CORS filter, you see the `Origin` and `X-TrafficPolicy-Header` headers. **CORS in HTTPRoute** ```console {hl_lines=[7,8,9]} HTTP/1.1 200 OK x-correlation-id: aaaaaaaa date: Tue, 24 Jun 2025 13:19:53 GMT content-length: 0 HTTP/1.1 200 OK access-control-allow-origin: https://example.com/ access-control-allow-credentials: true access-control-allow-methods: GET, POST, OPTIONS access-control-allow-headers: Origin, Authorization, Content-Type access-control-max-age: 86400 access-control-expose-headers: Origin, X-HTTPRoute-Header date: Tue, 24 Jun 2025 13:19:53 GMT server: envoy content-length: 0 ... ``` **CORS in EnterpriseKgatewayTrafficPolicy** ```console {hl_lines=[7,8,9]} HTTP/1.1 200 OK x-correlation-id: aaaaaaaa date: Tue, 24 Jun 2025 13:19:53 GMT content-length: 0 HTTP/1.1 200 OK access-control-allow-origin: https://example.com/ access-control-allow-credentials: true access-control-allow-methods: GET, POST, OPTIONS access-control-allow-headers: Origin, Authorization, Content-Type access-control-max-age: 86400 access-control-expose-headers: Origin, X-TrafficPolicy-Header date: Tue, 24 Jun 2025 13:19:53 GMT server: envoy content-length: 0 ```

2. Send another request to the httpbin app. This time, you use notallowed.com as your origin. Although the request succeeds, you do not get back your configured CORS settings such as max age, allowed origin, or allowed methods, because notallowed.com is not configured as a supported origin.

     curl -I -X OPTIONS http://$INGRESS_GW_ADDRESS:8080/get -H "host: cors.example:8080" \
    -H "Origin: https://notallowed.com/" \
    -H "Access-Control-Request-Method: POST" \
    -H "Access-Control-Request-Headers: Origin"
     

     curl -I -X OPTIONS localhost:8080/headers -H "host: cors.example:8080" \
    -H "Origin: https://notallowed.com/" \
    -H "Access-Control-Request-Method: POST" \
    -H "Access-Control-Request-Headers: Origin"
     

   Example output:

     HTTP/1.1 200 OK
   x-correlation-id: aaaaaaaa
   date: Tue, 24 Jun 2025 13:21:20 GMT
   content-length: 0
   
   HTTP/1.1 200 OK
   access-control-allow-credentials: true
   access-control-allow-headers: Origin
   access-control-allow-methods: GET, POST, HEAD, PUT, DELETE, PATCH, OPTIONS
   access-control-allow-origin: https://notallowed.com/
   access-control-max-age: 3600
   date: Tue, 24 Jun 2025 13:21:20 GMT
   content-length: 0
   x-envoy-upstream-service-time: 1
   server: envoy
     

Cleanup link

**CORS in HTTPRoute** ```sh kubectl delete httproute httpbin-cors -n httpbin ``` **CORS in EnterpriseKgatewayTrafficPolicy** ```sh kubectl delete httproute httpbin-cors -n httpbin kubectl delete EnterpriseKgatewayTrafficPolicy httpbin-cors -n httpbin ```

link