Tauri confuses people on CORS for one simple reason: it looks like a web app, but part of it behaves like a native app. That split changes what CORS does, where it applies, and how much protection you really get. If you build for the web first, your instinct is usually: “I’ll just fetch() the API from the frontend.” In Tauri, that can be correct, wrong, insecure, or just annoying depending on which runtime path you choose. ...
Retool makes it deceptively easy to wire up APIs fast. That’s great right up until the browser starts yelling about CORS and half the team decides “the API is broken.” Usually, the API is fine. The browser is doing exactly what it should do, and your Retool app is running into the same cross-origin rules as any other frontend. I’ve seen the same mistakes over and over with Retool setups: wrong origin assumptions, broken preflight handling, credentials mixed with wildcards, and APIs that technically work in Postman but fail instantly in the browser. Here’s the stuff that trips people up most often, and how I’d fix it. ...
CORS bugs on Scaleway usually aren’t really “Scaleway bugs.” They’re config mismatches between your browser app, your API, your object storage, and whatever proxy sits in front. I’ve seen teams burn hours blaming the platform when the actual problem was one missing header or a wildcard used in the wrong place. If you deploy frontends, APIs, or static assets on Scaleway, these are the mistakes that show up over and over. ...
Server-Sent Events look deceptively simple. Open a stream, keep writing data: lines, and the browser keeps listening. Then you put that stream on another origin and suddenly you’re debugging CORS, cookies, proxies, and browser quirks at 2 a.m. I’ve hit this enough times that I now treat SSE as “simple transport, annoying edge cases.” The CORS part is one of those edge cases. What CORS means for SSE SSE uses the browser’s EventSource API: ...
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. ...
CORS and service worker fetch events solve very different problems, but developers mix them up all the time. I’ve seen this happen in code reviews: someone adds a service worker and assumes it can magically bypass cross-origin restrictions. It cannot. A service worker can intercept requests from your origin, rewrite them, cache them, and synthesize responses. But it still runs inside the browser security model. CORS is still the gatekeeper for reading cross-origin responses. ...
A lot of CORS bugs don’t start in the app. They start at the edge. I’ve seen teams spend days debugging “random” frontend failures only to find the real issue sitting in a CDN rule added six months earlier by someone trying to improve cache hit ratio. The app was fine. The browser was fine. The CDN was serving the wrong CORS headers to the wrong origin. That’s the messy reality of global CDN configurations: once responses are cached and reused across regions, CORS mistakes get amplified fast. ...
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. ...
Admin panels are where CORS mistakes get expensive. A marketing site with sloppy CORS might leak some harmless JSON. An admin panel with sloppy CORS can expose user data, internal actions, billing operations, or account management APIs to the wrong origin. I’ve seen teams treat CORS like a checkbox, copy a wildcard policy from a public API, and accidentally turn a privileged backend into something any website can talk to. ...
Custom schemes are where a lot of clean CORS theory goes to die. On the web, most teams think in terms of https://app.example.com calling https://api.example.com. Then product ships a desktop app, a mobile WebView, or an Electron wrapper, and suddenly requests come from stuff like: myapp://local capacitor://localhost ionic://localhost tauri://localhost file:// null That’s when the usual “just set Access-Control-Allow-Origin” advice stops being enough. I’ve seen this play out on a desktop app rollout where the API worked perfectly in browsers, then failed in production for the packaged app. Same frontend code, same backend, same auth flow. The only difference was the request origin. ...