A few days ago, I ran into what I initially assumed was a typical CORS issue. I’ve handled CORS dozens of times, so I followed the usual checklist — checking headers, verifying allowed methods, reviewing proxy settings — but nothing resolved it.

After several hours of debugging, I discovered the actual cause had nothing to do with CORS at all.

The Problem

My backend was running inside a container, listening on port 6000. The frontend was making requests to this backend, and the browser responded with an error that looked like a CORS failure. But everything worked perfectly with curl and Postman. That’s when I realized something didn’t add up.

Eventually, I noticed a different message in Chrome’s dev tools:

ERR_UNSAFE_PORT

That’s when it clicked.

The Root Cause

Chrome blocks certain ports that it considers unsafe. These ports are associated with legacy protocols or services that could be exploited in specific scenarios — for example, hijacking FTP connections or bypassing firewall rules. Chrome restricts access to these ports to prevent potential abuse, even if you're working on localhost.

This behavior is browser-level. Tools like curl, Postman, or server logs won’t reflect this issue because they don’t apply the same security restrictions.

Why Chrome Does This

According to this explanation by Chris Siebenmann, Chrome’s port blocking is a preemptive security measure. The browser aims to prevent attackers from crafting web pages that send malicious requests to sensitive services running locally or within a network. Some of these services could interpret raw HTTP requests in dangerous ways if they receive traffic not intended for them.

These unsafe ports are hardcoded into Chromium’s source and affect all Chromium-based browsers. Other modern browsers like Firefox also implement similar restrictions, though the exact list may vary.

The Fix

If your application is running on one of these ports, the solution is simple: change the port. Stick to commonly used development ports. Avoid ports known to be reserved or flagged by browsers.

Final Thoughts

This issue is a good reminder that not all browser errors are what they seem. A CORS error might not always be a CORS problem. Sometimes the cause is more subtle — like the browser silently blocking your request because of the port number.

If you ever find yourself debugging a “CORS” issue that shouldn’t exist, double-check the port. It might save you hours.

When It’s Not CORS: The Case of Chrome’s Unsafe Ports