A lot of teams treat CORS like a checkbox: add Access-Control-Allow-Origin, ship it, move on. That usually works right up until the frontend needs one custom header, auth cookies enter the picture, or someone decides * is fine everywhere. I’ve seen this go wrong in a very normal setup: a React frontend on app.example.com, an API on api.example.com, and a CDN in front of both. Nothing exotic. The bug report sounded simple: ...
Cross-Origin-Embedder-Policy sounds abstract until it blows up a working app. I’ve seen this happen on teams that enabled Cross-Origin-Embedder-Policy: require-corp to unlock SharedArrayBuffer, improve isolation, or satisfy a performance-heavy feature using WebAssembly. Everything looked fine in local dev. Then production started blocking scripts, workers, fonts, and random third-party assets that had worked for years. The root problem usually isn’t COEP by itself. It’s that COEP forces you to be honest about cross-origin resource loading. And that means CORS suddenly matters for resources your app used to “just load.” ...
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. ...
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’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. ...
If you’re trying to call the Webflow CMS API from browser JavaScript, CORS is usually the first wall you hit. The short version: Webflow CMS API requests from the browser are a bad fit unless Webflow explicitly allows your origin. Even when the API works fine in Postman or curl, the browser enforces CORS and blocks the response before your code can touch it. This guide is the practical version: what CORS means for Webflow CMS, what will fail, what can work, and what to copy-paste. ...