Security

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

CORS gets messy fast in microservices. A single frontend might call an API gateway, which fans out to auth, billing, search, notifications, and a couple of legacy services nobody wants to touch. Then one team enables Access-Control-Allow-Origin: *, another requires cookies, a third forgets OPTIONS, and suddenly the browser is your loudest incident reporter. This guide is the version I wish more teams used: practical rules, copy-paste configs, and the stuff that breaks in real systems. ...

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

If you’ve worked with fetch() long enough, CORS feels familiar: preflights, Access-Control-Allow-Origin, blocked responses, weird credentials rules. Then you open a WebSocket from a browser and things get weird fast. You expect CORS to kick in. Usually it doesn’t. That surprises a lot of people because WebSockets start as an HTTP request. But the browser does not apply the normal CORS enforcement model to a WebSocket upgrade the same way it does for fetch() or XHR. Instead, browsers send an Origin header during the handshake, and the server is expected to decide whether to accept the connection. ...

Mobile developers get told weird things about CORS. I’ve heard all of these: “Mobile apps don’t use CORS.” “Just set Access-Control-Allow-Origin: * and move on.” “CORS is only a frontend problem.” “If the API is private, CORS doesn’t matter.” Some of that is half true, which is usually worse than being completely wrong. If you’re building a backend for iOS or Android, you need to understand when CORS applies, when it doesn’t, and why your support queue suddenly fills up the moment someone adds a webview, an admin dashboard, or a docs playground running in the browser. ...

CORS gets weird at the edge. On a normal app server, you usually control one thing: the response. At the edge, you control the response, the cache key, sometimes the request headers, and sometimes a chain of proxies you barely remember setting up six months ago. That’s where small CORS mistakes turn into “works in curl, fails in browser” bugs. This guide is the version I wish I had the first few times I debugged CORS on a CDN or edge worker. ...