Security

CORS: The Complete Handbook for Modern Web APIs Cross-Origin Resource Sharing, or CORS, is one of the most misunderstood parts of web development. Teams lose hours to it because the browser error messages feel vague, framework defaults vary wildly, and many blog posts reduce the topic to “just add Access-Control-Allow-Origin: *”. That advice is often wrong. CORS is not an authentication system, not a CSRF defense, and not a server-to-server access control mechanism. It is a browser-enforced policy layer that decides whether frontend JavaScript running on one origin may read a response from another origin. ...

VS Code webviews look like mini browser apps, so people assume normal browser networking rules apply cleanly. They don’t. That mismatch is where a lot of extension authors get stuck. I’ve seen this pattern over and over: fetch works in the extension host the same fetch fails in the webview people blame VS Code the real problem is CORS, sometimes mixed with CSP, origin quirks, or bad architecture If you’re building a VS Code extension with a webview, you need to treat the webview as an untrusted browser-like frontend and your extension host as the privileged backend. Once you do that, the design gets much cleaner. ...

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