Api-Security

A few months ago, I helped clean up a CORS mess on a small API running on Linode Akamai Compute. Nothing exotic: one frontend app, one backend API, both deployed fast, both working fine in local dev, and both breaking the minute a real browser got involved. That’s the pattern with CORS. Curl works. Postman works. Backend logs look healthy. Then the browser says no. This case study is for the setup I see all the time on Linode Akamai Compute: ...

CORS in Django REST Framework looks simple right up until your frontend starts throwing No 'Access-Control-Allow-Origin' header errors and every “quick fix” makes your API less safe. I’ve seen teams handle this in three common ways: disable CORS in development and forget about production slap Access-Control-Allow-Origin: * on everything actually configure it properly with environment-specific rules Only one of those scales without causing pain. The short version If you’re building a DRF API, your realistic CORS options are: ...

A few years ago I helped untangle a Drupal setup that looked fine in local dev and completely fell apart in production. The stack was common enough: Drupal serving JSON:API a separate frontend on another origin authenticated requests for logged-in users some custom headers from the frontend a CDN and reverse proxy in front of Drupal Everybody thought “CORS is enabled” meant the problem was solved. It wasn’t. The symptoms were classic: ...

If you call the Wix API from browser JavaScript, CORS is the gatekeeper. When it’s configured the way your frontend needs, everything feels normal. When it isn’t, you get the classic useless browser error: blocked by CORS policy. This guide is the version I wish I had the first time I tried wiring a frontend directly to a third-party API. What CORS means for Wix API CORS stands for Cross-Origin Resource Sharing. Browsers enforce it when your page on one origin tries to call an API on another origin. ...

Admin panels are where CORS mistakes get expensive. A marketing site with sloppy CORS might leak some harmless JSON. An admin panel with sloppy CORS can expose user data, internal actions, billing operations, or account management APIs to the wrong origin. I’ve seen teams treat CORS like a checkbox, copy a wildcard policy from a public API, and accidentally turn a privileged backend into something any website can talk to. ...

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

CORS in .NET Core and classic ASP.NET solve the same browser problem, but they feel very different once you actually ship APIs with them. If you’ve worked on both stacks, you’ve probably noticed the split right away: ASP.NET Core gives you a clean, policy-based CORS system built into the middleware pipeline. Classic ASP.NET usually feels more fragmented. Depending on whether you’re in Web API, MVC, IIS, or some mix of all three, CORS can be straightforward or weirdly annoying. That difference matters because CORS bugs are rarely “the browser is wrong.” Usually the server emitted the wrong headers, emitted them in the wrong order, or skipped them on preflight requests. ...

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

Mailgun webhooks and CORS get mixed up all the time, mostly because they solve different problems. Here’s the blunt version: Mailgun sending a webhook to your server does not need CORS Your browser calling your webhook endpoint does need CORS Your frontend should usually not call Mailgun directly That’s the whole mental model. If you keep those three rules straight, most confusion disappears. The short answer If Mailgun sends an event like delivered, opened, or failed to your backend: ...

Google Cloud Endpoints makes CORS feel simpler than it really is. That’s both the nice part and the dangerous part. If you’re running Endpoints with ESP or ESPv2, you’ve got a few ways to handle CORS: let Endpoints proxy and pass CORS through from your backend make Endpoints handle CORS preflight for you split responsibility between proxy and backend All three work. Not all three age well. I’ve seen teams “fix CORS” by slapping Access-Control-Allow-Origin: * onto everything, then later wonder why authenticated browser requests still fail. CORS is one of those areas where the browser is very literal, and Google Cloud Endpoints doesn’t save you from bad policy choices. ...