Web IDE: Duplicate Access-Control-Allow-Origin header breaks functionality on instances with custom CORS policies

Background

A self-managed customer using the Omnibus package has a custom CORS policy configured via nginx['custom_gitlab_server_config'] in their gitlab.rb. This setting injects the following directives into their NGINX configuration:

add_header 'Access-Control-Allow-Origin' 'customer.gitlab.url' always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET,HEAD,OPTIONS,POST,PUT' always;
add_header 'Access-Control-Allow-Headers' 'Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, Authorization' always;
proxy_cookie_path / '/; HTTPOnly; SameSite=None; Secure';

This is the NGINX custom_gitlab_server_config described here: https://docs.gitlab.com/omnibus/settings/nginx/#insert-custom-nginx-settings-into-the-gitlab-server-block

They are currently running GitLab 18.1.2 in production and are testing version 18.2.1 in their development environments.

Upon testing version 18.2, they observed that the Web IDE switched to loading assets from cdn.web-ide.gitlab-static.net. This change introduced a new Access-Control-Allow-Origin: * header from the GitLab application. The customer had previously encountered a similar issue on version 18.1.2 when they briefly enabled the extension marketplace, which also resulted in a CORS failure.

The introduction of the VSCode-based Web IDE and its reliance on a multi-domain architecture (as detailed in gitlab-org/gitlab#526383 and !193417 (merged)) appears to be the trigger for this conflict.

Problem to solve

The Access-Control-Allow-Origin: * header added by the GitLab application conflicts with the customer's pre-existing, more restrictive CORS policy set in their NGINX configuration. This results in the server sending two Access-Control-Allow-Origin headers in its response.

Web browsers correctly interpret this as a misconfiguration and block the request, throwing a CORS error. This breaks critical Web IDE functionality, such as populating the repository file list.

The customer needs a way to manage CORS policies without conflict. Specifically, they want to remove the wildcard * origin and specify their own list of allowed origins.