Resolving a Mysterious CSS CORS Issue During Frontend Migration to Cloud

During a migration of frontend assets to a cloud provider, the author discovered a puzzling CORS issue where a specific CSS resource was blocked by the browser, causing the entire project to become unusable.

What is a cross‑origin problem? In web development, a cross‑origin request occurs when the protocol, domain, or port of a resource differs from the page’s origin. The browser’s same‑origin policy blocks such requests unless the server supplies appropriate CORS headers.

Typical triggers include different domains, protocols, ports, or sub‑domains, each illustrated with examples such as example.com requesting api.example.net , HTTPS loading HTTP resources, or mismatched ports like example.com:3000 versus example.com:4000 .

Common ways to solve CORS problems are listed: enabling CORS headers on the server, using JSONP, setting up a proxy server, employing window.postMessage() , leveraging WebSocket, or configuring an Nginx reverse proxy.

Project background – The author managed a micro‑frontend migration to Alibaba Cloud OSS, combining multiple applications. Three resource‑loading approaches were considered: direct OSS URLs, CDN‑based URLs, and internal server proxies. Each method has trade‑offs regarding latency, security, and maintainability.

Specific issue – Only one CSS file returned without the Access-Control-Allow-Origin header, while HTML and JS files were fine. Investigation showed that the CDN had cached the CSS response when the initial browser request lacked an Origin header, so the cached version never contained CORS headers.

Root cause analysis – Directly opening the CSS URL in a browser (outside of a page load) does not trigger the same‑origin policy, so no Origin header is sent. OSS therefore omitted the CORS header, and the CDN cached that header‑less response. Subsequent page loads always received the cached version, perpetuating the problem.

Solution – Ensure every request to OSS includes an Origin header. The author added an Nginx location block that forwards the incoming Origin or substitutes a default value, then purged the cached CSS file or forced a cache‑bypass with a query string.

Example Nginx configuration:

location ~ ^/(message|dygateway|logcenter)/tice/ {
    set $cors_origin "";
    if ($http_origin = "") {
        set $cors_origin 'static.example.com';
    }
    if ($http_origin != "") {
        set $cors_origin $http_origin;
    }
    proxy_set_header Origin $cors_origin;
}

After clearing the CDN cache, the CSS file returned the correct CORS headers and the application worked normally.

Three practical CORS configuration options are presented:

OSS bucket CORS rules – simple UI configuration, high security, but vendor‑specific.

Gateway server (Nginx) headers – flexible for any environment, but requires Nginx expertise.

CDN edge CORS settings – high performance and scalability, though potentially costly and more complex.

Sample generic Nginx CORS snippet:

location / {
    add_header 'Access-Control-Allow-Origin' '*';
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE';
    add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
}

To bust the stale cache, the author appended a dummy query string to the CSS URL, e.g., https://static.company.com/productdata/gateway-admin/prod/assets/index-a12abcbf.css?abc=111 , which forced the CDN to fetch a fresh response with proper CORS headers.

In conclusion, a thorough analysis of the request chain, careful handling of the Origin header, and appropriate CORS configuration on OSS, the gateway, or the CDN can reliably eliminate similar cross‑origin issues in frontend projects.