CORS errors on all nginx vhosts — missing headers caused customer login failures #1

New Issue

2026-06-15T13:22:07-04:00

hiveiq commented

2026-06-15 13:22:07 -04:00

Summary

All nginx vhosts (14 frontend domains + auth.bcos.cloud + api.bcos.cloud) were missing CORS headers. This caused browser CORS errors for customers logging in from the desktop browser app and for any cross-origin API call between SPAs.

Root Cause

Each service has its own nginx vhost conf file (analytics.conf, fleet.conf, profile.conf, etc.). None had CORS configuration. Preflight OPTIONS requests were proxied straight to Spring Security, which rejected them with 403 Invalid CORS request if the origin was not in CORS_ALLOWED_ORIGINS.

Additionally, Spring Security was rejecting same-origin form submissions from the Electron auth window because Chromium adds an Origin header on form POSTs, and api.bcos.cloud was not in the allowed origins list.

Fix Applied (2026-06-15)

Nginx is now the single authoritative CORS handler — Spring Security never sees the Origin header.

New files added to nginx conf.d/:

cors_map.conf — origin whitelist (*.bcos.cloud, *.bcos.dev, localhost dev ports) mapped to $cors_allowed_origin
cors_include.conf — reusable snippet included in every location block:
- Strips upstream CORS headers (proxy_hide_header) to prevent duplicates
- Strips Origin from upstream request (proxy_set_header Origin "") to prevent Spring Security CORS rejection
- Injects Access-Control-* headers from the validated origin map
- Re-adds security headers (HSTS, X-Frame-Options, etc.)

Files patched (added cors_include + OPTIONS 204 to every location block):
api.conf, auth.conf, adoons.conf, analytics.conf, claims.conf, dashboard.conf, devices.conf, fleet.conf, mgmt.conf, messaging.conf, msp.conf, profile.conf, recon.conf, reports.conf, transactions.conf, vault.conf

Impact

AOCU customers could not log in via the desktop browser app
QDS users hitting CORS errors on login
profile.bcos.cloud failed to load after login (auth.bcos.cloud had no CORS headers)

Follow-up

These nginx conf files are not in source control. They should be versioned in hiveiq-ops so future vhosts get the CORS pattern from day one. Any new vhost must include cors_include.conf in every location block.

## Summary All nginx vhosts (14 frontend domains + auth.bcos.cloud + api.bcos.cloud) were missing CORS headers. This caused browser CORS errors for customers logging in from the desktop browser app and for any cross-origin API call between SPAs. ## Root Cause Each service has its own nginx vhost conf file (analytics.conf, fleet.conf, profile.conf, etc.). None had CORS configuration. Preflight OPTIONS requests were proxied straight to Spring Security, which rejected them with 403 Invalid CORS request if the origin was not in CORS_ALLOWED_ORIGINS. Additionally, Spring Security was rejecting same-origin form submissions from the Electron auth window because Chromium adds an Origin header on form POSTs, and api.bcos.cloud was not in the allowed origins list. ## Fix Applied (2026-06-15) Nginx is now the single authoritative CORS handler — Spring Security never sees the Origin header. New files added to nginx conf.d/: - cors_map.conf — origin whitelist (*.bcos.cloud, *.bcos.dev, localhost dev ports) mapped to $cors_allowed_origin - cors_include.conf — reusable snippet included in every location block: - Strips upstream CORS headers (proxy_hide_header) to prevent duplicates - Strips Origin from upstream request (proxy_set_header Origin "") to prevent Spring Security CORS rejection - Injects Access-Control-* headers from the validated origin map - Re-adds security headers (HSTS, X-Frame-Options, etc.) Files patched (added cors_include + OPTIONS 204 to every location block): api.conf, auth.conf, adoons.conf, analytics.conf, claims.conf, dashboard.conf, devices.conf, fleet.conf, mgmt.conf, messaging.conf, msp.conf, profile.conf, recon.conf, reports.conf, transactions.conf, vault.conf ## Impact - AOCU customers could not log in via the desktop browser app - QDS users hitting CORS errors on login - profile.bcos.cloud failed to load after login (auth.bcos.cloud had no CORS headers) ## Follow-up These nginx conf files are not in source control. They should be versioned in hiveiq-ops so future vhosts get the CORS pattern from day one. Any new vhost must include cors_include.conf in every location block.

hiveiq added the Bug

Priority

High

labels 2026-06-15 13:22:07 -04:00

hiveiq self-assigned this 2026-06-15 13:22:07 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hiveiq-src/hiveiq-ops#1