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: ...
Browsers used to treat “public website calls my router or local dev box” as mostly a weird edge case. That changed. Private Network Access, or PNA, adds another browser-enforced check when a page on a less-private network tries to reach a more-private one. If you build APIs, admin panels, local device UIs, or anything that runs on localhost, your CORS setup now has a second layer to think about. The short version: ...
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. ...
CORS gets weird fast once a CDN sits in front of your app. Without a CDN, you mostly think about browser rules: Origin, preflights, Access-Control-Allow-Origin, maybe credentials. Add a CDN and now you also have cache keys, header normalization, OPTIONS caching, stale variants, and the classic bug where one origin gets cached and leaked to another. I’ve seen teams debug this for hours because the app server was “correct” but the CDN was serving the wrong cached CORS headers. ...
If you’ve worked with fetch() long enough, CORS feels familiar: preflights, Access-Control-Allow-Origin, blocked responses, weird credentials rules. Then you open a WebSocket from a browser and things get weird fast. You expect CORS to kick in. Usually it doesn’t. That surprises a lot of people because WebSockets start as an HTTP request. But the browser does not apply the normal CORS enforcement model to a WebSocket upgrade the same way it does for fetch() or XHR. Instead, browsers send an Origin header during the handshake, and the server is expected to decide whether to accept the connection. ...
Mobile developers get told weird things about CORS. I’ve heard all of these: “Mobile apps don’t use CORS.” “Just set Access-Control-Allow-Origin: * and move on.” “CORS is only a frontend problem.” “If the API is private, CORS doesn’t matter.” Some of that is half true, which is usually worse than being completely wrong. If you’re building a backend for iOS or Android, you need to understand when CORS applies, when it doesn’t, and why your support queue suddenly fills up the moment someone adds a webview, an admin dashboard, or a docs playground running in the browser. ...
Every time your React app sends a JSON POST request, the browser does something you might not expect: it sends TWO requests instead of one. The first is an OPTIONS “preflight” request. The second is your actual request. This confuses a lot of people. Why is the browser sending extra requests? Why is my API getting OPTIONS requests I never wrote endpoints for? Why does Postman work but the browser doesn’t? ...