That CORS error? It wasn't my code

Sarvesh Sakpal — Sun, 26 Jul 2026 15:52:01 +0000

I learned something interesting while debugging Apache, Express, and CORS.
Seeing a CORS error in the browser doesn't necessarily mean your Express CORS configuration is broken.
I had a frontend sending requests to an API through Apache:
Frontend → Browser → Apache → Express (server.js)
The browser was showing a CORS error.
My first thought was naturally:
“Something must be wrong with my CORS configuration.”
But the interesting part was that the request wasn't even reaching server.js.
That changed how I looked at the problem.
CORS is enforced by the browser. If Apache, a reverse proxy, or another layer returns/fails with a response that doesn't contain the expected CORS headers, the browser can surface it as a CORS error.
So:
Browser shows CORS error ≠ request definitely reached your application.
Another thing I learned while debugging the same proxy setup was the importance of forwarded headers.
My flow looked like:
Browser → HTTPS → Apache → HTTP → Express
Apache terminates HTTPS, so Express's direct connection can be HTTP even though the client originally connected using HTTPS.
That's where:
X-Forwarded-Proto: https
becomes important.
It tells the backend that the original client connection was HTTPS.
And on the Express side:
app.set("trust proxy", 1)
tells Express to trust proxy information according to the configured proxy topology.
This becomes especially important with things like:
cookie: { secure: true }
because your application needs to correctly understand whether the original request was secure.
A useful debugging lesson I took from this:
Don't debug only the error shown by the browser. Debug the entire request path.
Browser → DNS/TLS → Reverse Proxy → Application → Response → Browser
Sometimes the error you see at the frontend is only the symptom, not where the actual failure happened.

DEV Community: Sarvesh Sakpal

That CORS error? It wasn't my code