Security

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

A lot of CORS bugs are really OAuth2 architecture bugs wearing a fake mustache. I’ve seen teams spend days tweaking Access-Control-Allow-Origin headers when the real problem was simpler: they were trying to run the wrong OAuth2 flow in the browser, or they expected the browser to carry cookies and tokens across origins in ways it never will. Here’s a case study based on a very normal setup: frontend: https://app.example.com API: https://api.example.com auth server: https://auth.example.com The team had a React SPA talking directly to the API. They wanted users to click “Login with OAuth”, get redirected to the auth server, come back with a session, and then call the API with fetch(). ...

I’ve heard developers say “I need to add CORS to my API for security” more times than I can count. That’s backwards. CORS doesn’t make your API more secure. In fact, it makes it less restricted. The security feature is the Same-Origin Policy. CORS is the controlled exception. Let me clear this up once and for all. Same-Origin Policy (SOP) The Same-Origin Policy is a built-in browser security mechanism. It’s been around since the early days of the web. Here’s what it does: ...

You’ve built a React frontend. You’ve built a Node.js API. They work perfectly when you test them separately. You wire them together, make your first API call, and… Access to fetch at 'http://localhost:3001/api/users' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Sound familiar? Every developer hits this wall. And most developers respond by Googling “how to fix CORS” and pasting app.use(cors()) without understanding what they just did. ...