Security

Headless CMS preview sounds simple until the browser gets involved. Your editor clicks “Preview draft”, your frontend tries to fetch unpublished content from a CMS API on another origin, and suddenly the browser throws a CORS error that says almost nothing useful. I’ve seen teams lose hours here because they treated preview like normal production API traffic. It isn’t. Preview usually combines the hardest parts of cross-origin browser security in one flow: ...

Cloudflare Access is great at putting identity in front of internal apps and APIs. CORS is great at making frontend apps talk to APIs across origins. Put them together and you get a setup that works well — until it really doesn’t. I’ve seen teams assume Cloudflare Access will “just handle” cross-origin browser requests. It won’t. Access solves authentication and authorization at the edge. CORS is still your job, and the browser is still brutally strict about it. ...

CORS on Vultr is usually not a Vultr problem. It’s an app server, reverse proxy, or object storage config problem that just happens to show up on a Vultr VM, Kubernetes cluster, or load balancer. I’ve seen teams lose hours blaming firewalls, DNS, even TLS, when the real bug was one missing OPTIONS response or a wildcard used with credentials. So here’s the practical version: what to set, where to set it, and what not to do. ...

CORS with Cloudflare Zero Trust tends to fail in ways that look random until you understand who is actually answering the browser. That’s the first mistake: treating CORS like an app-only problem when Cloudflare is sitting in front of your app, enforcing Access policies, redirecting unauthenticated users, and sometimes answering OPTIONS before your origin ever sees it. If you’ve ever said “but my API sends Access-Control-Allow-Origin just fine” while the browser still throws a CORS error, this is probably why. ...

CORS and Linkerd live at different layers, and that mismatch is where most confusion starts. Linkerd is a service mesh. CORS is a browser enforcement model for cross-origin HTTP requests. Linkerd is great at mTLS, traffic policy, retries, and observability between services. It is not, by itself, a CORS engine. If you expect Linkerd to “handle CORS” the way an API gateway or app framework does, you’ll hit a wall pretty quickly. ...

A lot of teams assume Azure Front Door will “handle CORS” because it sits in front of everything. That assumption burns time. I’ve seen this play out the same way more than once: the API works in Postman, works from curl, even works when you hit the backend directly — but the browser says no. Then someone starts adding random Access-Control-* headers at Front Door, somebody else enables caching, and suddenly the failures become intermittent. That’s when the real fun starts. ...

If you build with SST long enough, you’ll eventually hit the classic wall: “Blocked by CORS policy” And the annoying part is that SST usually makes the happy path feel simple. Then one custom header, one cookie-based auth flow, or one frontend deployed to a different domain later, and you’re deep in browser errors that barely explain what’s actually wrong. Here are the CORS mistakes I see most often in SST projects, plus the fixes that actually work. ...

I’ve seen the same Cloud Run rollout go sideways more than once: the service works in curl, works in Postman, even works from server-side code — then the browser blocks it and everyone blames Google. Usually, Cloud Run is innocent. The app is returning the wrong CORS headers, returning them inconsistently, or forgetting that browsers send a completely separate preflight request before the “real” one. Here’s a real-world style case study based on a pattern I’ve had to fix in production. ...

Internal dashboards are where bad CORS habits go to hide. I’ve seen teams lock down customer-facing APIs pretty well, then turn around and ship an admin panel that talks to five internal services with Access-Control-Allow-Origin: *, cookies flying around, and preflights failing randomly because nobody remembers which proxy strips which header. Internal tooling feels “safe” because it lives behind SSO, VPN, or a corporate network. That mindset causes sloppy CORS configs. Browsers don’t care that your app is “internal.” They still enforce the same rules, and attackers love soft targets with elevated access. ...

VS Code webviews look like mini browser apps, so people assume normal browser networking rules apply cleanly. They don’t. That mismatch is where a lot of extension authors get stuck. I’ve seen this pattern over and over: fetch works in the extension host the same fetch fails in the webview people blame VS Code the real problem is CORS, sometimes mixed with CSP, origin quirks, or bad architecture If you’re building a VS Code extension with a webview, you need to treat the webview as an untrusted browser-like frontend and your extension host as the privileged backend. Once you do that, the design gets much cleaner. ...