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 Azure API Management looks easy right up until the browser starts throwing useless errors and your API works fine in Postman. That’s the trap: CORS is a browser enforcement layer, and APIM adds another layer of policy behavior on top of it. If you put the policy in the wrong scope, return the wrong origin, or forget how preflight requests work, you get a mess that’s hard to debug. ...

If you try to call the BigCommerce REST Management API directly from browser JavaScript, you’re going to hit a wall. Not because your fetch() code is wrong, but because CORS is doing exactly what it’s supposed to do. BigCommerce has multiple API surfaces, and they do not behave the same way from a browser. That distinction matters: Storefront APIs are designed for browser-facing use cases Management APIs are meant for trusted server-side access CORS policy decides whether the browser will even allow your frontend code to read the response That’s the part people usually miss. The request may leave the browser just fine, but if the response doesn’t include the right CORS headers, your app still fails. ...

CORS for WPGraphQL usually gets treated like a checkbox: “just add Access-Control-Allow-Origin and move on.” That’s how you end up with broken auth, failed preflights, or a GraphQL endpoint that quietly accepts requests from places it shouldn’t. If you’re exposing /graphql from WordPress, CORS deserves a deliberate setup. WPGraphQL makes WordPress feel like an app backend, which means browsers start enforcing cross-origin rules in ways a normal PHP theme never had to care about. ...

Capacitor sits in an awkward but very practical place: your app looks like a website, runs in a WebView, but ships like a native app. That hybrid setup changes how CORS behaves, and a lot of advice written for regular websites breaks down fast. If you’ve ever thought: “My API works in Chrome but not in Capacitor” “Why is my app origin capacitor://localhost?” “Why do cookies disappear on mobile?” “Why does native HTTP magically bypass CORS?” You’re in the right place. ...

CORS gets blamed for a lot of things it didn’t do. Half the time the server is fine and the browser is blocking access on purpose. The other half, someone added mode: "no-cors" and made the problem harder to debug. This guide is the practical version: what the browser actually gives you, what “opaque” really means, and how to make cross-origin responses readable. The short version When your frontend calls another origin, the browser decides whether JavaScript can read the response. ...

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.” ...