Express

CORS on Render usually fails for boring reasons: the wrong origin, missing preflight handling, or a preview URL you forgot to allow. If you deploy APIs or frontends on Render, you’ll hit this fast. Your frontend lives at one origin, your API at another, and the browser blocks requests unless the API sends the right Access-Control-* headers. Render itself doesn’t “do CORS” for your app. Your service has to return the headers. That’s the part many people miss. ...

I’ve seen a lot of teams blame Heroku when their frontend suddenly starts throwing CORS errors after deployment. Usually, Heroku is not the problem. Heroku just makes bad CORS assumptions painfully visible. This case study comes from a very common setup: React frontend on one Heroku app or a custom domain Node/Express API on another Heroku app Everything works locally Production blows up with No 'Access-Control-Allow-Origin' header is present The painful part is that the app often looks fine in Postman, curl, or server-to-server tests. Then the browser blocks it anyway. ...

Shopify webhooks and CORS get mixed up constantly. I’ve seen teams burn hours “fixing CORS” on webhook endpoints that were never touched by a browser in the first place. Shopify sends webhooks server-to-server. Browsers enforce CORS. Those are different worlds. So the short version is: Shopify webhook delivery does not require CORS Your frontend talking to your backend may require CORS Your webhook endpoint should usually not be exposed for browser cross-origin access at all That distinction saves a lot of confusion. ...

CORS on Railway usually breaks for the same boring reasons it breaks everywhere else: wrong origin, missing preflight handling, credentials mixed with *, or a proxy layer eating headers. Railway itself is not the hard part. Your app is. This guide is the version I wish I could paste into every “CORS error on Railway” thread. What Railway changes Railway gives you deployed services on Railway-owned domains and often custom domains on top. That means your frontend and backend commonly end up on different origins: ...

CORS with GraphQL looks simple right up until the browser starts throwing vague errors and your API “works in curl” but fails in production. I’ve seen this a lot with Apollo Server because GraphQL teams tend to focus on schema design and resolvers, then treat HTTP as plumbing. Browsers do not care how elegant your schema is. If your CORS policy is wrong, the app breaks anyway. Here are the mistakes I see most often with Apollo Server, why they happen, and how to fix them without turning your API into Access-Control-Allow-Origin: * soup. ...

CORS on AWS ECS Fargate usually goes wrong for one boring reason: people configure it in the wrong layer. I’ve seen teams add CORS headers in app code, then put an ALB, CloudFront, Nginx, or API Gateway in front of it and accidentally strip or duplicate headers. Then the browser says “CORS failed” and everybody starts guessing. Here’s the practical way to think about it: Browser enforces CORS Your backend must return the right headers Every proxy in front of your app must preserve them Preflight OPTIONS requests must succeed You cannot “fix CORS” from frontend code If your app runs on ECS Fargate, CORS is not an ECS feature. ECS just runs containers. The actual CORS behavior comes from whatever is serving traffic: ...

tRPC is great right up until your frontend and API live on different origins and the browser starts throwing CORS errors that look unrelated to your code. I’ve seen this happen a lot with tRPC because the transport feels “magic” when everything is same-origin. Then you split your app across app.example.com and api.example.com, or you run Vite on localhost:5173 against a backend on localhost:3000, and suddenly every request is blocked before your resolver runs. ...

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

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

Express makes CORS relatively painless, but there are a few gotchas that catch people off guard. Let me walk through every setup I’ve seen work in production. The cors Package (Easiest Option) npm install cors The One-Liner (Development Only) const cors = require('cors'); app.use(cors()); ```text This allows all origins, all methods, all headers. Fine for local development. Do NOT use this in production. ### Allow a Single Origin ```javascript const cors = require('cors'); app.use(cors({ origin: 'https://myapp.com', methods: ['GET', 'POST', 'PUT', 'DELETE'], allowedHeaders: ['Content-Type', 'Authorization'], credentials: true, maxAge: 86400, })); Allow Multiple Origins This is where it gets slightly tricky. The cors package doesn’t accept an array for origin — it accepts a function: ...