November 2, 2026
CORS Misconfiguration: The Bug Hiding in One Response Header
Why a single `Access-Control-Allow-Origin` reflection can quietly hand over someone’s entire account
By Monika
4 min read
There's a header most developers set once, early in a project, and never look at again: Access-Control-Allow-Origin. It's one line in a config file, usually added in a hurry to stop the browser console from screaming about CORS errors during development. And then it ships to production exactly as it was written for testing — wide open.
CORS (Cross-Origin Resource Sharing) exists for a good reason: by default, your browser won't let a script on evil.com read data from bank.com just because you happen to be logged into both. CORS is the mechanism that relaxes that rule, selectively, when a server explicitly says "yes, this other origin is allowed to read my responses." The bug happens when that permission is handed out far too loosely — sometimes to literally anyone who asks.
How to actually see what's happening
Open Burp Suite, visit any API endpoint on the target that requires authentication, and look at the response headers. You're hunting for two specific lines appearing together:
Access-Control-Allow-Origin: https://evil.com…Access-Control-Allow-Origin: https://evil.com…