ingress-nginx: nginx.ingress.kubernetes.io/cors-allow-origin doesn't seem to work?

In my case was that the backend was returning wrong CORS headers (Allow *) and nginx is not overwritting them. If backend sends an *, nginx just append it to the nginx.ingress.kubernetes.io/cors-allow-origin response header. Is there a way to overwrite this behaviour without modifying the backend?

Is there any movement on this? It looks like there’s a PR… I really need this working.

I had a similar issue (getting CORS issues in Burp Suite Vulnerability test) and, it finally worked with this:

If I Remove any cors related annotation, and add:

    nginx.ingress.kubernetes.io/server-snippet: |
      add_header Access-Control-Allow-Origin "https://*.example.com";

it returns the right header (Access-Control-Allow-Origin: https://*.example.com) but fails in Burp Suite Vulnerability test.

If I add also nginx.ingress.kubernetes.io/enable-cors: 'true'

Returns also the ‘Access-Control-Allow-Origin: *’ header but passes the Vulnerability test.

I hope that this maybe helps someone

@rudolfbyker case3 & case4 are a cause of concern.

• There has been at least 1 change to harden the use of CORS in the past year
• Could you kindly write a step-by-step doc that someone can copy/paste from to reproduce on a minikube or a kind cluster. I think its important that we clarify the status in clear unambiguous data
• The project is in a stabilization phase but close to completing the stabilization work. So if this is a bug, then it will be taken up after ending the stabilization work that is in progress now
• In case this is an issue and in case a PR comes in from community, it will be appreciated and reviewed sooner

I will try to take a look at this when I have time Until then feel free to comment 😃

The expected behavior for the CORS preflight request (the OPTIONS request) is that the server responds to all requests, regardless of origin, to indicate what type of requests are allowed on the resource. Browsers use the results of preflight requests to determine if the actual requests should be sent. The Mozilla CORS documentation describes this requirement. Without responding to the preflight request for non-allowed origins, the browser cannot decide that it is unsafe to send the original request, which is the purpose of setting up CORS in nginx.

To handle multiple allowed origins, the server also needs to set the Vary response header to Origin to indicate to browsers that the response can change based on the Origin request header. This way different allowed-origins can be returned and the browser can handle caching the information appropriately.

What is not clear is how origins with wildcarded subdomains should be handled because it doesn’t appear that https://*.example.com is a valid value for Access-Control-Allow-Origin. I think it’s unclear how a browser might choose to handle such a response. Maybe a nginx.ingress.kubernetes.io/cors-default-allow-origin value is required when wildcarded subdomains are used? For a strict list of valid allowed origins, I think it’s acceptable just to return one of them as long as the Vary header is set.

Thanks for the pointer to the e2e tests. I think what’s missing are the tests for the preflight requests specifically, which is the trueoptions branch in the current implementation. I don’t see coverage for OPTIONS requests from either an allowed origin or a non-allowed origin. I think what we need here is essentially a falseoptions branch that can handle multiple allowed origins and wildcarded subdomains and then all the e2e tests.

I opened https://github.com/kubernetes/ingress-nginx/pull/10490 that may fix the issue with multiple allowed origins. Please have a look. Thank you @michaelliau for the heads-up!

I’m having the same, or similar issue. Let me demonstrate what I get in the /etc/nginx/nginx.conf in the controller pod in response to various annotations:

Case 1: All origins, no credentials.

This works.

nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, PATCH, OPTIONS"
nginx.ingress.kubernetes.io/cors-allow-origin: "*"
nginx.ingress.kubernetes.io/cors-allow-credentials: "false"

set $http_origin *;
set $cors 'true';

if ($request_method = 'OPTIONS') {
    set $cors ${cors}options;
}

if ($cors = "true") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    
    more_set_headers 'Access-Control-Allow-Methods: PUT, GET, POST, PATCH, OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    
    more_set_headers 'Access-Control-Max-Age: 1728000';
}

if ($cors = "trueoptions") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    
    more_set_headers 'Access-Control-Allow-Methods: PUT, GET, POST, PATCH, OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    
    more_set_headers 'Access-Control-Max-Age: 1728000';
    more_set_headers 'Content-Type: text/plain charset=UTF-8';
    more_set_headers 'Content-Length: 0';
    return 204;
}

Case 2: All origins, with credentials

This does not work, because of line set $http_origin *;. This discards the Origin value set in the browser and uses the literal “*”, which is only supported when Access-Control-Allow-Credentials is false. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin#directives .

nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, PATCH, OPTIONS"
nginx.ingress.kubernetes.io/cors-allow-origin: "*"
nginx.ingress.kubernetes.io/cors-allow-credentials: "true"

set $http_origin *;
set $cors 'true';

if ($request_method = 'OPTIONS') {
    set $cors ${cors}options;
}

if ($cors = "true") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    more_set_headers 'Access-Control-Allow-Credentials: true'; 
    more_set_headers 'Access-Control-Allow-Methods: PUT, GET, POST, PATCH, OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    
    more_set_headers 'Access-Control-Max-Age: 1728000';
}

if ($cors = "trueoptions") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    more_set_headers 'Access-Control-Allow-Credentials: true'; 
    more_set_headers 'Access-Control-Allow-Methods: PUT, GET, POST, PATCH, OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    
    more_set_headers 'Access-Control-Max-Age: 1728000';
    more_set_headers 'Content-Type: text/plain charset=UTF-8';
    more_set_headers 'Content-Length: 0';
    return 204;
}

Case 3: Specific origin, with credentials

This does not work, because the $cors variable is never set, only read. This must surely be a bug!

nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, PATCH, OPTIONS"
nginx.ingress.kubernetes.io/cors-allow-origin: {{ .Values.global.domain }}
nginx.ingress.kubernetes.io/cors-allow-credentials: "true"

if ($request_method = 'OPTIONS') {
    set $cors ${cors}options;
}

if ($cors = "true") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    more_set_headers 'Access-Control-Allow-Credentials: true'; 
    more_set_headers 'Access-Control-Allow-Methods: PUT, GET, POST, PATCH, OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    
    more_set_headers 'Access-Control-Max-Age: 1728000';
}

if ($cors = "trueoptions") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    more_set_headers 'Access-Control-Allow-Credentials: true'; 
    more_set_headers 'Access-Control-Allow-Methods: PUT, GET, POST, PATCH, OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    
    more_set_headers 'Access-Control-Max-Age: 1728000';
    more_set_headers 'Content-Type: text/plain charset=UTF-8';
    more_set_headers 'Content-Length: 0';
    return 204;
}

Case 4: Specific origin, without credentials

Same issue as case 3 above.

nginx.ingress.kubernetes.io/enable-cors: "true"
nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, PATCH, OPTIONS"
nginx.ingress.kubernetes.io/cors-allow-origin: {{ .Values.global.domain }}
nginx.ingress.kubernetes.io/cors-allow-credentials: "false"

if ($request_method = 'OPTIONS') {
    set $cors ${cors}options;
}

if ($cors = "true") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    
    more_set_headers 'Access-Control-Allow-Methods: PUT, GET, POST, PATCH, OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    
    more_set_headers 'Access-Control-Max-Age: 1728000';
}

if ($cors = "trueoptions") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    
    more_set_headers 'Access-Control-Allow-Methods: PUT, GET, POST, PATCH, OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
    
    more_set_headers 'Access-Control-Max-Age: 1728000';
    more_set_headers 'Content-Type: text/plain charset=UTF-8';
    more_set_headers 'Content-Length: 0';
    return 204;
}

I came across this issue while I was battling with CORS deployed in ingress-nginx because a web server I deployed did not ship it in its configuration, so I wanted to add it in nginx instead.

I was confused when I did not get the expected CORS behaviour when enabling cors and setting the expected allowed-origin(s) when testing with cURL:

❯ curl -i -XOPTIONS https://qa.example.org/api
HTTP/2 405
date: Tue, 09 Aug 2022 11:39:25 GMT
content-length: 0
allow: GET
x-api-version: foo-service
x-response-time-ms: 0
strict-transport-security: max-age=15724800; includeSubDomains

Setting the allowed origins to * made it work (as reported here as well). However, when I read the generated config posted here https://github.com/kubernetes/ingress-nginx/issues/8469#issuecomment-1194784059, I see that the first line requires the request to contain the Origin header to match the query and therefore respond appropriately. I added this in my cURL request and voilá, the CORS headers I expected:

❯ curl -i -XOPTIONS -H "Origin: https://qa.example.org" https://qa.example.org/api
HTTP/2 204
date: Tue, 09 Aug 2022 11:39:35 GMT
strict-transport-security: max-age=15724800; includeSubDomains
access-control-allow-origin: https://qa.example.org
access-control-allow-credentials: true
access-control-allow-methods: GET, PUT, POST, DELETE, PATCH, OPTIONS
access-control-allow-headers: DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization
access-control-expose-headers: x-api-version,x-response-time-ms
access-control-max-age: 1728000

Not sure if this is the case for anyone here, but in case it is, I thought I’d share. 😃

Annotations for this ingress:

{
  "kubernetes.io/ingress.class": "nginx",
  "nginx.ingress.kubernetes.io/cors-allow-credentials": "true",
  "nginx.ingress.kubernetes.io/cors-allow-origin": "https://qa.example.org,https://subdomain.qa.example.org",
  "nginx.ingress.kubernetes.io/cors-expose-headers": "x-api-version,x-response-time-ms",
  "nginx.ingress.kubernetes.io/enable-cors": "true",
  "nginx.ingress.kubernetes.io/service-upstream": "true"
}

I’m experiencing the same behavior. For OPTIONS requests coming from origins which do not match the allowed-origins configured through nginx.ingress.kubernetes.io/cors-allow-origin, there are no returned CORS headers. This is resulting in browsers thinking CORS is disabled.

I believe the issue is with how nginx.conf is being generated. Here’s what I get generated for cors-allow-origin=https://*.mydomain.com:

if ($http_origin ~* ((https://[A-Za-z0-9\-]+\.mydomain\.com))$ ) { set $cors 'true'; }

if ($request_method = 'OPTIONS') {
    set $cors ${cors}options;
}

if ($cors = "true") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    more_set_headers 'Access-Control-Allow-Credentials: true';
    more_set_headers 'Access-Control-Allow-Methods: GET,PUT,POST,DELETE,PATCH,OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: accept,allow,x-my-custom-header';

    more_set_headers 'Access-Control-Max-Age: 1728000';
}

if ($cors = "trueoptions") {
    more_set_headers 'Access-Control-Allow-Origin: $http_origin';
    more_set_headers 'Access-Control-Allow-Credentials: true';
    more_set_headers 'Access-Control-Allow-Methods: GET,PUT,POST,DELETE,PATCH,OPTIONS';
    more_set_headers 'Access-Control-Allow-Headers: accept,allow,x-my-custom-header';

    more_set_headers 'Access-Control-Max-Age: 1728000';
    more_set_headers 'Content-Type: text/plain charset=UTF-8';
    more_set_headers 'Content-Length: 0';
    return 204;
}

The issue is that there’s no handling for non-allowed-origin matching OPTIONS requests. I see the OPTIONS requests from non-allowed origins falling through to my API servers, resulting in 404s because OPTIONS is not supported at that layer. The generated configuration needs to handle these requests and return a valid value for Access-Control-Allow-Origin. I believe the issue was introduced when support for multiple allowed origins was added. Maybe @larivierec has some insight here.