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

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

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

If you’ve ever shipped a frontend against AWS API Gateway, you’ve probably had that moment: the API works fine in Postman, maybe even with curl, but the browser throws a CORS error and gives you almost nothing useful. That’s the thing about CORS with API Gateway: the browser enforces it, API Gateway partially helps, and your backend can still ruin everything. I’ve seen teams lose hours because they enabled “CORS” in the console and assumed they were done. Usually they weren’t. ...