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.” ...
Tauri confuses people on CORS for one simple reason: it looks like a web app, but part of it behaves like a native app. That split changes what CORS does, where it applies, and how much protection you really get. If you build for the web first, your instinct is usually: “I’ll just fetch() the API from the frontend.” In Tauri, that can be correct, wrong, insecure, or just annoying depending on which runtime path you choose. ...
Retool makes it deceptively easy to wire up APIs fast. That’s great right up until the browser starts yelling about CORS and half the team decides “the API is broken.” Usually, the API is fine. The browser is doing exactly what it should do, and your Retool app is running into the same cross-origin rules as any other frontend. I’ve seen the same mistakes over and over with Retool setups: wrong origin assumptions, broken preflight handling, credentials mixed with wildcards, and APIs that technically work in Postman but fail instantly in the browser. Here’s the stuff that trips people up most often, and how I’d fix it. ...
CORS bugs on Scaleway usually aren’t really “Scaleway bugs.” They’re config mismatches between your browser app, your API, your object storage, and whatever proxy sits in front. I’ve seen teams burn hours blaming the platform when the actual problem was one missing header or a wildcard used in the wrong place. If you deploy frontends, APIs, or static assets on Scaleway, these are the mistakes that show up over and over. ...
Server-Sent Events look deceptively simple. Open a stream, keep writing data: lines, and the browser keeps listening. Then you put that stream on another origin and suddenly you’re debugging CORS, cookies, proxies, and browser quirks at 2 a.m. I’ve hit this enough times that I now treat SSE as “simple transport, annoying edge cases.” The CORS part is one of those edge cases. What CORS means for SSE SSE uses the browser’s EventSource API: ...
CORS and API versioning tend to collide in ugly ways once an API leaves the whiteboard and hits browsers, CDNs, mobile clients, and a few years of “temporary” backwards compatibility. I’ve seen teams treat them as separate concerns: versioning is for API design, CORS is for frontend access. That split works right up until you ship v2, your browser app starts sending different headers, preflights spike, and suddenly half your cross-origin traffic is failing for reasons no one can reproduce with curl. ...