Nodejs

GitHub webhooks and CORS get mixed together constantly, and that usually leads to the wrong architecture. Here’s the blunt version: GitHub webhooks do not need CORS. Browsers need CORS. GitHub’s webhook delivery system is server-to-server HTTP. If GitHub is POSTing an event to your endpoint, CORS is irrelevant because no browser is enforcing cross-origin restrictions. The browser is the thing that cares about Access-Control-Allow-Origin, preflights, and exposed headers. GitHub’s webhook infrastructure does not. ...

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

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

If you build a frontend that calls Firebase Functions from a different origin, CORS stops being “that browser thing” and turns into a real deployment concern fast. Firebase gives you a few ways to deal with CORS, and they’re not equal. Some are clean and low-friction. Some are easy to misuse. Some look secure until you add credentials and realize you just shipped a broken policy. Here’s the practical comparison guide I wish more people had before copy-pasting Access-Control-Allow-Origin: * into every function. ...

Express makes CORS relatively painless, but there are a few gotchas that catch people off guard. Let me walk through every setup I’ve seen work in production. The cors Package (Easiest Option) npm install cors The One-Liner (Development Only) const cors = require('cors'); app.use(cors()); ```text This allows all origins, all methods, all headers. Fine for local development. Do NOT use this in production. ### Allow a Single Origin ```javascript const cors = require('cors'); app.use(cors({ origin: 'https://myapp.com', methods: ['GET', 'POST', 'PUT', 'DELETE'], allowedHeaders: ['Content-Type', 'Authorization'], credentials: true, maxAge: 86400, })); Allow Multiple Origins This is where it gets slightly tricky. The cors package doesn’t accept an array for origin — it accepts a function: ...