Headers

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

CORS gets weird the moment DNS enters the room. A lot of teams assume that if they point api.example.com to a vendor with a CNAME, the browser will somehow treat that endpoint as “same-origin enough” with app.example.com. It won’t. Browsers care about origin, not your DNS intent. A custom subdomain can make things cleaner for cookies, branding, and certificate management, but it does not magically bypass CORS. That distinction matters when you’re choosing between: ...

This is the page I keep coming back to when I need to remember the exact syntax or behavior of a CORS header. I’m putting it all in one place so you don’t have to hunt through MDN and Stack Overflow. Response Headers (What Your Server Sends) These are the headers your API server needs to send. The browser reads these to decide whether to allow the cross-origin request. Access-Control-Allow-Origin The single most important CORS header. Without it, nothing works. ...