Javascript

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

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 on AWS API Gateway HTTP APIs looks simple right up until your browser starts throwing No 'Access-Control-Allow-Origin' header and your backend logs show everything is “working fine.” I’ve hit this enough times that I now treat CORS as part browser contract, part API Gateway feature, and part trap. This guide is about API Gateway HTTP APIs specifically, not the older REST API product. The behavior is different enough that mixing them up causes bad advice and wasted hours. ...

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

Mailgun webhooks and CORS get mixed up all the time, mostly because they solve different problems. Here’s the blunt version: Mailgun sending a webhook to your server does not need CORS Your browser calling your webhook endpoint does need CORS Your frontend should usually not call Mailgun directly That’s the whole mental model. If you keep those three rules straight, most confusion disappears. The short answer If Mailgun sends an event like delivered, opened, or failed to your backend: ...

Webhook signature verification and CORS get mixed up all the time, usually in bad ways. The short version: webhook verification with HMAC should almost always happen server-side, and CORS is only relevant if a browser is calling your verification endpoint. A webhook provider like GitHub, Stripe, or Slack is not a browser. It does not care about Access-Control-Allow-Origin. That distinction saves a lot of confusion. The mental model There are really two separate flows: ...

CORS in Deno and Bun feels similar at first because both runtimes lean hard into the Web Platform. You get Request, Response, Headers, and fetch, so the mechanics are familiar. The difference shows up when you actually wire policies into a real server, especially once preflight requests, credentials, and route-level behavior enter the picture. My short take: Deno feels more explicit and standards-first. Bun feels faster to get running and very ergonomic, but you need to be just as disciplined about the policy because neither runtime magically saves you from bad CORS decisions. ...

COOP and CORS get mixed together all the time, and I get why. They both have “cross-origin” in the name, both involve headers, and both can break your app in ways that feel random. But they solve different problems. CORS controls whether a page can read a cross-origin HTTP response in JavaScript. COOP, via the Cross-Origin-Opener-Policy header, controls whether a top-level document stays in the same browsing context group as pages it opens or pages that open it. That affects window.opener, popup relationships, process isolation, and features like SharedArrayBuffer when combined with other 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. ...