Fetch

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

If you’ve ever opened an HTML file directly in the browser and watched fetch() explode with a CORS error, you’ve hit one of the weirdest corners of web security: file://. I’ve seen this trip up experienced developers, not just beginners. The usual reaction is: “But I’m not even cross-origin. It’s just a local file.” The browser disagrees. The core problem with file:// A page loaded from file:///Users/me/demo/index.html does not behave like a normal web app served from http://localhost. Browsers treat file:// as a special origin, and in many cases as an opaque origin or at least something heavily restricted. That means requests from a local file to: ...

CORS in Microsoft Edge extensions trips people up because extensions are not normal web pages, but they’re also not completely exempt from browser security rules. I’ve seen teams waste hours debugging a “CORS issue” that was actually a host permission problem, a content script limitation, or a server sending the wrong headers. If you build Edge extensions, you need to separate three execution contexts in your head: Content scripts Extension pages like popup, options, side panel Background/service worker That distinction explains most CORS bugs. ...