Security

CORS: The Complete Handbook for Modern Web APIs Cross-Origin Resource Sharing, or CORS, is one of the most misunderstood parts of web development. Teams lose hours to it because the browser error messages feel vague, framework defaults vary wildly, and many blog posts reduce the topic to “just add Access-Control-Allow-Origin: *”. That advice is often wrong. CORS is not an authentication system, not a CSRF defense, and not a server-to-server access control mechanism. It is a browser-enforced policy layer that decides whether frontend JavaScript running on one origin may read a response from another origin. ...

CORS in Traefik is mostly a headers middleware problem. Once you get that, the config becomes pretty mechanical. The annoying part is that browsers are strict, Traefik is flexible, and bad examples online often mix app-level CORS with proxy-level CORS. I usually prefer handling CORS at the edge in Traefik when multiple services need the same behavior. It keeps backend apps simpler and avoids five different teams all inventing slightly broken header logic. ...

Teams hit a weird wall with React Native WebView all the time: the same API call works fine in native code, then suddenly fails when it runs inside a WebView. People call it “a React Native bug” or “an Android thing.” Most of the time, it’s just CORS doing exactly what the browser engine inside the WebView is supposed to do. I’ve seen this happen in hybrid apps that embed a React checkout flow, an admin dashboard, or a support portal. The native shell works. The web app inside the shell blows up with “Network request failed,” “Origin null is not allowed,” or a preflight that never gets approved. ...

AWS AppSync looks simple from the browser: send a GraphQL POST, get JSON back, move on. Then CORS shows up and burns half a day. I’ve seen the same pattern over and over: the GraphQL API works in Postman, works in the AWS console, maybe even works from a local script, but the browser throws a CORS error that tells you almost nothing useful. AppSync is especially good at this because the problem is often not “CORS in AppSync” by itself. It’s usually some combination of custom domains, auth mode, preflight behavior, CloudFront, cookies, or headers your frontend is trying to send. ...

Real-time apps make CORS weirder than plain old fetch(). A normal API request is easy to reason about: browser sends an Origin, server returns Access-Control-Allow-Origin, done. Real-time stacks like Socket.IO and SignalR add negotiation endpoints, long polling fallbacks, credentials, sticky sessions, and WebSocket upgrades. That combination creates the kind of bug where everything works locally, then production starts throwing “CORS policy blocked” while your websocket dashboard looks perfectly healthy. I’ve hit this enough times that I now treat real-time CORS as a separate problem, not just “API CORS but more.” ...

Headless CMS preview sounds simple until the browser gets involved. Your editor clicks “Preview draft”, your frontend tries to fetch unpublished content from a CMS API on another origin, and suddenly the browser throws a CORS error that says almost nothing useful. I’ve seen teams lose hours here because they treated preview like normal production API traffic. It isn’t. Preview usually combines the hardest parts of cross-origin browser security in one flow: ...

Cloudflare Access is great at putting identity in front of internal apps and APIs. CORS is great at making frontend apps talk to APIs across origins. Put them together and you get a setup that works well — until it really doesn’t. I’ve seen teams assume Cloudflare Access will “just handle” cross-origin browser requests. It won’t. Access solves authentication and authorization at the edge. CORS is still your job, and the browser is still brutally strict about it. ...

CORS on Vultr is usually not a Vultr problem. It’s an app server, reverse proxy, or object storage config problem that just happens to show up on a Vultr VM, Kubernetes cluster, or load balancer. I’ve seen teams lose hours blaming firewalls, DNS, even TLS, when the real bug was one missing OPTIONS response or a wildcard used with credentials. So here’s the practical version: what to set, where to set it, and what not to do. ...

CORS with Cloudflare Zero Trust tends to fail in ways that look random until you understand who is actually answering the browser. That’s the first mistake: treating CORS like an app-only problem when Cloudflare is sitting in front of your app, enforcing Access policies, redirecting unauthenticated users, and sometimes answering OPTIONS before your origin ever sees it. If you’ve ever said “but my API sends Access-Control-Allow-Origin just fine” while the browser still throws a CORS error, this is probably why. ...

CORS and Linkerd live at different layers, and that mismatch is where most confusion starts. Linkerd is a service mesh. CORS is a browser enforcement model for cross-origin HTTP requests. Linkerd is great at mTLS, traffic policy, retries, and observability between services. It is not, by itself, a CORS engine. If you expect Linkerd to “handle CORS” the way an API gateway or app framework does, you’ll hit a wall pretty quickly. ...