Nginx

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

I’ve seen the same CORS mess play out on Hetzner boxes more than once: the app works locally, staging kind of works, then production starts throwing browser errors that look random until you realize the reverse proxy, the API, and the frontend all disagree about who is allowed to talk to whom. This case study comes from a very normal setup on Hetzner Cloud: frontend on app.example.com API on api.example.com Nginx on the VPS as reverse proxy Node.js API behind it TLS terminated at Nginx a second environment for previews on *.staging.example.com The team had deployed cleanly. DNS was right. Certificates were fine. Curl looked fine. The browser was not fine. ...

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

Setting CORS at the web server level is often the cleanest approach. Your application doesn’t need to know about CORS at all — Nginx or Apache handles it before the request even reaches your app. Here are configurations I’ve used in production that work. Nginx Basic: Single Origin server { listen 80; server_name api.example.com; location / { add_header Access-Control-Allow-Origin "https://myapp.com"; add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"; add_header Access-Control-Allow-Headers "Content-Type, Authorization"; add_header Access-Control-Allow-Credentials "true"; add_header Access-Control-Max-Age "86400"; add_header Access-Control-Expose-Headers "X-Total-Count, X-Request-Id"; # Handle preflight if ($request_method = OPTIONS) { add_header Access-Control-Allow-Origin "https://myapp.com"; add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"; add_header Access-Control-Allow-Headers "Content-Type, Authorization"; add_header Access-Control-Allow-Credentials "true"; add_header Access-Control-Max-Age "86400"; return 204; } proxy_pass http://127.0.0.1:3000; } } Note: You need to repeat the add_header directives inside the if block because Nginx’s if directive creates a new context. Headers set outside the if don’t apply inside it. This is a well-known Nginx gotcha. ...