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

I’ve seen the same CORS mess play out on Hetzner boxes more than once: the app works locally, staging kind of works, then production starts throwing browser errors that look random until you realize the reverse proxy, the API, and the frontend all disagree about who is allowed to talk to whom. This case study comes from a very normal setup on Hetzner Cloud: frontend on app.example.com API on api.example.com Nginx on the VPS as reverse proxy Node.js API behind it TLS terminated at Nginx a second environment for previews on *.staging.example.com The team had deployed cleanly. DNS was right. Certificates were fine. Curl looked fine. The browser was not fine. ...

Google Cloud Endpoints makes CORS feel simpler than it really is. That’s both the nice part and the dangerous part. If you’re running Endpoints with ESP or ESPv2, you’ve got a few ways to handle CORS: let Endpoints proxy and pass CORS through from your backend make Endpoints handle CORS preflight for you split responsibility between proxy and backend All three work. Not all three age well. I’ve seen teams “fix CORS” by slapping Access-Control-Allow-Origin: * onto everything, then later wonder why authenticated browser requests still fail. CORS is one of those areas where the browser is very literal, and Google Cloud Endpoints doesn’t save you from bad policy choices. ...

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

Webhook security and CORS get mixed together all the time, and that usually leads to one of two bad outcomes: people add CORS headers to webhook endpoints that never needed them people assume CORS protects webhook endpoints from abuse It does neither. Here’s the blunt version: CORS is a browser policy, not an authentication system, not an origin firewall, and definitely not webhook verification. If your payment provider, GitHub app, or internal service is sending server-to-server webhooks, CORS is usually irrelevant. ...

CORS on Azure Functions looks simple until you ship something with auth, multiple environments, and a frontend team that keeps changing origins every sprint. I’ve seen teams treat CORS as a checkbox in the Azure Portal, then spend hours debugging why Authorization headers fail, why local dev works but production doesn’t, or why preflight requests get blocked before their function code even runs. If you’re building browser-facing APIs on Azure Functions, you have a few ways to handle CORS. Some are easy. Some are flexible. Some are traps. ...

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

CORS and CSRF get lumped together way too often. I’ve seen teams say “we enabled CORS, so we’re protected from CSRF now” and then act surprised when their app still has a cross-site request forgery bug. That’s the core mistake: these are not competing solutions to the same problem. They deal with different threats, at different layers, using different browser behavior. If you only remember one thing, make it this: ...

If you build a Rails API and your frontend runs on a different origin, CORS stops being theory pretty fast. You ship an endpoint, the browser blocks it, and suddenly everyone is staring at a console error that says “No ‘Access-Control-Allow-Origin’ header.” Rails itself does not magically solve CORS. You need to configure it intentionally, and if you get lazy with wildcards or credentials, you can open up more access than you meant to. ...