Security

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

If you’re trying to call the Webflow API directly from browser JavaScript, CORS is the first wall you hit. And honestly, that wall exists for a good reason. Webflow’s API is meant for authenticated server-side use in most real applications. Frontend devs still try to wire it straight into a Webflow site, React app, or embedded widget because it feels faster. Sometimes it even works during early testing. Then auth headers, preflight requests, token exposure, or browser restrictions ruin the plan. ...

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

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

CORS on API Gateway looks easy until the browser starts throwing vague errors and Terraform happily deploys a broken setup. I’ve hit this enough times that I now treat CORS as a first-class part of the API contract, not a checkbox. If you manage AWS API Gateway with Terraform, the main thing to remember is this: CORS is enforced by browsers, but you implement it in API Gateway and your backend responses. ...

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

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

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

GraphQL subscriptions are where CORS advice usually gets sloppy. A lot of teams learn CORS from regular fetch() requests, then bolt on subscriptions and assume the same rules apply. They do not. The transport matters: HTTP GraphQL queries/mutations: normal CORS rules WebSocket subscriptions: not governed by browser CORS in the same way SSE subscriptions: back to normal HTTP-origin behavior Multipart/deferred streaming over HTTP: also normal CORS behavior If you only remember one thing, remember this: GraphQL subscriptions over WebSocket do not use CORS the way fetch() does, but origin validation still matters. ...

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