Api

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

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

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

CORS performance usually gets treated like background noise until your frontend starts making hundreds of API calls and every second request triggers an OPTIONS preflight. Then it becomes very obvious: bad CORS config can waste latency, server CPU, and CDN cache efficiency. I’ve seen teams obsess over query performance while every browser quietly burns extra round trips on preflights they could have avoided. This guide is the practical version: what gets cached, what does not, and what headers to set when you want cross-origin requests to be fast without turning your policy into mush. ...

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

CORS in a Flutter WebView trips people up because there are really two different worlds hiding behind one app: Flutter web, where your app runs in a browser and CORS rules fully apply. Flutter mobile with a WebView, where browser-like behavior exists, but native networking and embedded browser behavior can change the story. If you treat a WebView like “just Chrome inside Flutter,” you’ll misdiagnose bugs for hours. I’ve done that. The fix usually starts with one question: ...

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