Javascript

I’ve seen the same Netlify Edge Functions CORS bug more times than I can count: the function works perfectly in curl, looks fine in local testing, then the browser blows up with a vague CORS error and the frontend team starts blaming fetch. Usually the problem is simple. The Edge Function returns JSON, but forgets the preflight request, forgets Vary: Origin, or hardcodes * while also trying to send cookies. That combo is enough to turn a clean deployment into an afternoon of browser-tab archaeology. ...

A lot of teams assume Azure Front Door will “handle CORS” because it sits in front of everything. That assumption burns time. I’ve seen this play out the same way more than once: the API works in Postman, works from curl, even works when you hit the backend directly — but the browser says no. Then someone starts adding random Access-Control-* headers at Front Door, somebody else enables caching, and suddenly the failures become intermittent. That’s when the real fun starts. ...

I’ve seen the same Cloud Run rollout go sideways more than once: the service works in curl, works in Postman, even works from server-side code — then the browser blocks it and everyone blames Google. Usually, Cloud Run is innocent. The app is returning the wrong CORS headers, returning them inconsistently, or forgetting that browsers send a completely separate preflight request before the “real” one. Here’s a real-world style case study based on a pattern I’ve had to fix in production. ...

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

VS Code webviews look like mini browser apps, so people assume normal browser networking rules apply cleanly. They don’t. That mismatch is where a lot of extension authors get stuck. I’ve seen this pattern over and over: fetch works in the extension host the same fetch fails in the webview people blame VS Code the real problem is CORS, sometimes mixed with CSP, origin quirks, or bad architecture If you’re building a VS Code extension with a webview, you need to treat the webview as an untrusted browser-like frontend and your extension host as the privileged backend. Once you do that, the design gets much cleaner. ...

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

If you’re trying to call the Webflow API directly from browser JavaScript, CORS is the first wall you hit. And honestly, that wall exists for a good reason. Webflow’s API is meant for authenticated server-side use in most real applications. Frontend devs still try to wire it straight into a Webflow site, React app, or embedded widget because it feels faster. Sometimes it even works during early testing. Then auth headers, preflight requests, token exposure, or browser restrictions ruin the plan. ...

If you call the Wix API from browser JavaScript, CORS is the gatekeeper. When it’s configured the way your frontend needs, everything feels normal. When it isn’t, you get the classic useless browser error: blocked by CORS policy. This guide is the version I wish I had the first time I tried wiring a frontend directly to a third-party API. What CORS means for Wix API CORS stands for Cross-Origin Resource Sharing. Browsers enforce it when your page on one origin tries to call an API on another origin. ...