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

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

GitHub webhooks and CORS get mixed together constantly, and that usually leads to the wrong architecture. Here’s the blunt version: GitHub webhooks do not need CORS. Browsers need CORS. GitHub’s webhook delivery system is server-to-server HTTP. If GitHub is POSTing an event to your endpoint, CORS is irrelevant because no browser is enforcing cross-origin restrictions. The browser is the thing that cares about Access-Control-Allow-Origin, preflights, and exposed headers. GitHub’s webhook infrastructure does not. ...

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

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

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

A few years ago I helped untangle a Drupal setup that looked fine in local dev and completely fell apart in production. The stack was common enough: Drupal serving JSON:API a separate frontend on another origin authenticated requests for logged-in users some custom headers from the frontend a CDN and reverse proxy in front of Drupal Everybody thought “CORS is enabled” meant the problem was solved. It wasn’t. The symptoms were classic: ...