Backend

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

I’ve seen a lot of Go APIs ship with one of two CORS setups: AllowOrigins: ["*"] and a prayer no CORS config at all, followed by frontend people yelling in Slack Both work fine right up until browsers get involved. This case study is based on a pretty typical setup: a Go backend serving JSON to a separate frontend app, first on localhost, then across staging and production domains. The backend started on Gin, another service used Echo, and both had the same problem: “it works in curl” but fails in the browser. ...

Telegram bot webhooks and CORS are a weird combo, mostly because people often try to solve the wrong problem. Here’s the blunt version: Telegram does not care about CORS when delivering webhooks to your server. Browsers care about CORS. Telegram is not a browser. So if your bot backend receives webhook requests from Telegram, CORS is irrelevant for that inbound traffic. Where CORS does matter is when you put a browser app in front of your bot infrastructure and that browser tries to call your webhook endpoint, bot API proxy, status endpoint, or admin interface. ...

CORS in Actix-web is one of those things that looks trivial until your frontend starts failing with mysterious preflight errors at 2 AM. Rust gives you strong guarantees around memory safety. CORS gives you sharp edges around browser behavior. Different problem space entirely. If you’re building APIs with Actix-web, you’ll usually end up choosing between a few practical CORS strategies: * for public APIs strict allowlists for browser apps dynamic origin handling for multi-tenant setups “just reflect the origin” hacks you probably shouldn’t ship I’ll compare those approaches, show where Actix-web fits well, and point out the tradeoffs that actually matter in production. ...

A lot of teams treat CORS like a checkbox: add Access-Control-Allow-Origin, ship it, move on. That usually works right up until the frontend needs one custom header, auth cookies enter the picture, or someone decides * is fine everywhere. I’ve seen this go wrong in a very normal setup: a React frontend on app.example.com, an API on api.example.com, and a CDN in front of both. Nothing exotic. The bug report sounded simple: ...

Cross-Origin-Embedder-Policy sounds abstract until it blows up a working app. I’ve seen this happen on teams that enabled Cross-Origin-Embedder-Policy: require-corp to unlock SharedArrayBuffer, improve isolation, or satisfy a performance-heavy feature using WebAssembly. Everything looked fine in local dev. Then production started blocking scripts, workers, fonts, and random third-party assets that had worked for years. The root problem usually isn’t COEP by itself. It’s that COEP forces you to be honest about cross-origin resource loading. And that means CORS suddenly matters for resources your app used to “just load.” ...

CORS and API versioning tend to collide in ugly ways once an API leaves the whiteboard and hits browsers, CDNs, mobile clients, and a few years of “temporary” backwards compatibility. I’ve seen teams treat them as separate concerns: versioning is for API design, CORS is for frontend access. That split works right up until you ship v2, your browser app starts sending different headers, preflights spike, and suddenly half your cross-origin traffic is failing for reasons no one can reproduce with curl. ...

If you’re trying to call the Squarespace API from browser JavaScript, you’ll run into CORS fast. That usually looks like this: fetch("https://api.squarespace.com/1.0/sites", { headers: { Authorization: "Bearer YOUR_TOKEN" } }) And then the browser smacks you with a CORS error. The annoying part is that your token might be valid, the endpoint might be correct, and the API might work perfectly in cURL or Postman. But the browser still blocks it. That’s not a Squarespace bug. That’s the browser enforcing Cross-Origin Resource Sharing. ...

CORS in Deno and Bun feels similar at first because both runtimes lean hard into the Web Platform. You get Request, Response, Headers, and fetch, so the mechanics are familiar. The difference shows up when you actually wire policies into a real server, especially once preflight requests, credentials, and route-level behavior enter the picture. My short take: Deno feels more explicit and standards-first. Bun feels faster to get running and very ergonomic, but you need to be just as disciplined about the policy because neither runtime magically saves you from bad CORS decisions. ...

Mobile developers get told weird things about CORS. I’ve heard all of these: “Mobile apps don’t use CORS.” “Just set Access-Control-Allow-Origin: * and move on.” “CORS is only a frontend problem.” “If the API is private, CORS doesn’t matter.” Some of that is half true, which is usually worse than being completely wrong. If you’re building a backend for iOS or Android, you need to understand when CORS applies, when it doesn’t, and why your support queue suddenly fills up the moment someone adds a webview, an admin dashboard, or a docs playground running in the browser. ...