Web-Security

Chrome extensions live in a weird middle ground. They’re not normal web pages, but they’re not fully trusted native apps either. That matters a lot for CORS. If you build extensions long enough, you hit this fast: fetch() works in your background service worker the same request fails in a content script adding Access-Control-Allow-Origin to your request does nothing people tell you to “just use host_permissions” and then preflights still surprise you The mental model that has saved me the most time is this: ...

If you’ve ever tried calling a Magento REST API from a separate frontend and hit a browser error that looks vague, annoying, and borderline insulting, that was probably CORS. Magento itself usually isn’t the whole problem. The browser is enforcing the policy, your web server is often the layer that needs fixing, and authentication makes everything more fragile. Here’s the practical version: if your React, Vue, Next.js, or plain JavaScript app lives on https://storefront.example and your Magento API lives on https://shop.example, the browser treats that as cross-origin. Even if both domains are yours. ...

CORS on Render usually fails for boring reasons: the wrong origin, missing preflight handling, or a preview URL you forgot to allow. If you deploy APIs or frontends on Render, you’ll hit this fast. Your frontend lives at one origin, your API at another, and the browser blocks requests unless the API sends the right Access-Control-* headers. Render itself doesn’t “do CORS” for your app. Your service has to return the headers. That’s the part many people miss. ...

CORS in Spring Boot looks easy right up until the browser starts throwing vague errors and your API “works in Postman” but fails in Chrome. That’s the normal path. Spring Boot gives you a few different places to configure CORS, and that flexibility is exactly why teams end up with broken preflight requests, duplicated headers, or insecure wildcard rules in production. I’ve seen all three. This guide covers how CORS actually works in a Spring Boot app, when to use each configuration style, and the mistakes that tend to waste the most time. ...

I’ve seen a lot of Go APIs ship with one of two CORS setups: AllowOrigins: ["*"] and a prayer no CORS config at all, followed by frontend people yelling in Slack Both work fine right up until browsers get involved. This case study is based on a pretty typical setup: a Go backend serving JSON to a separate frontend app, first on localhost, then across staging and production domains. The backend started on Gin, another service used Echo, and both had the same problem: “it works in curl” but fails in the browser. ...

Make (formerly Integromat) is great at stitching APIs together. The trouble starts when you try to involve a browser. A lot of developers assume this flow will work: frontend app calls API directly Make scenario orchestrates some backend steps browser reads the response and moves on Then CORS shows up and ruins the afternoon. The core problem: Make runs server-to-server just fine, but browsers enforce CORS and Make does not magically bypass that for your frontend. If your app calls an API from the browser, the API still needs the right CORS headers. If your app calls a Make webhook from the browser, that webhook also needs to behave in a browser-friendly way. ...

If you build internal tools with Appsmith, you will hit CORS sooner or later. Usually it happens like this: your API works fine in Postman or curl, then Appsmith tries to call it from the browser and everything blows up with a vague “blocked by CORS policy” error. That is not Appsmith being weird. That is the browser enforcing cross-origin rules exactly as designed. This guide is the copy-paste version I wish more teams had. No fluff, just what matters for Appsmith apps. ...

CORS in Actix-web is one of those things that looks trivial until your frontend starts failing with mysterious preflight errors at 2 AM. Rust gives you strong guarantees around memory safety. CORS gives you sharp edges around browser behavior. Different problem space entirely. If you’re building APIs with Actix-web, you’ll usually end up choosing between a few practical CORS strategies: * for public APIs strict allowlists for browser apps dynamic origin handling for multi-tenant setups “just reflect the origin” hacks you probably shouldn’t ship I’ll compare those approaches, show where Actix-web fits well, and point out the tradeoffs that actually matter in production. ...

Multi-region APIs are great right up until the browser gets involved. Your backend can happily serve traffic from us-east-1, eu-west-1, and ap-southeast-1, but once a frontend starts calling those endpoints cross-origin, CORS becomes one of the easiest ways to break an otherwise solid deployment. I’ve seen teams spend days debugging “random” browser failures that turned out to be region-specific CORS drift. If you run APIs behind a CDN, global load balancer, edge worker, or region-aware gateway, you need to treat CORS as part of your routing architecture, not just a couple of headers added somewhere in Express. ...

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