Web-Security

If you deploy APIs on Fly.io, CORS usually stops being “just a browser thing” the moment your frontend hits production. Locally, everything works. Then your app lands behind Fly Proxy, gets a custom domain, maybe a second region, and suddenly your browser starts yelling about preflights and missing Access-Control-Allow-Origin. The good news: Fly.io doesn’t make CORS unusually hard. The bad news: Fly.io also doesn’t magically solve it for you. You still need to decide where CORS lives, how strict it should be, and how it behaves across preview apps, custom domains, and edge-facing traffic. ...

Discord bot developers hit the same wall over and over: the bot works fine from Node.js, then somebody adds a web dashboard and the browser starts screaming about CORS. I’ve seen this happen with moderation bots, music bots, internal community tools, and “quick” admin panels that turned into production apps. The pattern is predictable: the bot token works on the server somebody tries to call Discord directly from frontend JavaScript preflight requests fail, or worse, the token gets exposed the team starts sprinkling Access-Control-Allow-Origin: * everywhere and hopes for the best That’s not how you want to build a Discord bot dashboard. ...

Chrome platform apps have always been a weird corner of the web platform. They look like web apps, use web APIs, and make HTTP requests like a browser. But they also run with elevated privileges and their network behavior does not match a normal tab. If you work on CORS-heavy APIs, that difference matters. This guide is the practical version: what changes, what still applies, and what headers you actually need. ...

A lot of teams treat CORS like a checkbox: add Access-Control-Allow-Origin, ship it, move on. That usually works right up until the frontend needs one custom header, auth cookies enter the picture, or someone decides * is fine everywhere. I’ve seen this go wrong in a very normal setup: a React frontend on app.example.com, an API on api.example.com, and a CDN in front of both. Nothing exotic. The bug report sounded simple: ...

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

Caddy makes the easy path easy, but CORS is still CORS. The browser enforces it, the server has to answer correctly, and one wrong header can turn a simple API call into a weird frontend bug that eats an afternoon. This guide is the version I wish I had the first few times I configured CORS behind a reverse proxy. What CORS is actually doing CORS is the browser asking: ...

I’ve seen the same Netlify Edge Functions CORS bug more times than I can count: the function works perfectly in curl, looks fine in local testing, then the browser blows up with a vague CORS error and the frontend team starts blaming fetch. Usually the problem is simple. The Edge Function returns JSON, but forgets the preflight request, forgets Vary: Origin, or hardcodes * while also trying to send cookies. That combo is enough to turn a clean deployment into an afternoon of browser-tab archaeology. ...

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

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

Cross-Origin-Embedder-Policy sounds abstract until it blows up a working app. I’ve seen this happen on teams that enabled Cross-Origin-Embedder-Policy: require-corp to unlock SharedArrayBuffer, improve isolation, or satisfy a performance-heavy feature using WebAssembly. Everything looked fine in local dev. Then production started blocking scripts, workers, fonts, and random third-party assets that had worked for years. The root problem usually isn’t COEP by itself. It’s that COEP forces you to be honest about cross-origin resource loading. And that means CORS suddenly matters for resources your app used to “just load.” ...