Api

CORS: The Complete Handbook for Modern Web APIs Cross-Origin Resource Sharing, or CORS, is one of the most misunderstood parts of web development. Teams lose hours to it because the browser error messages feel vague, framework defaults vary wildly, and many blog posts reduce the topic to “just add Access-Control-Allow-Origin: *”. That advice is often wrong. CORS is not an authentication system, not a CSRF defense, and not a server-to-server access control mechanism. It is a browser-enforced policy layer that decides whether frontend JavaScript running on one origin may read a response from another origin. ...

If you try to call the BigCommerce REST Management API directly from browser JavaScript, you’re going to hit a wall. Not because your fetch() code is wrong, but because CORS is doing exactly what it’s supposed to do. BigCommerce has multiple API surfaces, and they do not behave the same way from a browser. That distinction matters: Storefront APIs are designed for browser-facing use cases Management APIs are meant for trusted server-side access CORS policy decides whether the browser will even allow your frontend code to read the response That’s the part people usually miss. The request may leave the browser just fine, but if the response doesn’t include the right CORS headers, your app still fails. ...

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

CORS for WPGraphQL usually gets treated like a checkbox: “just add Access-Control-Allow-Origin and move on.” That’s how you end up with broken auth, failed preflights, or a GraphQL endpoint that quietly accepts requests from places it shouldn’t. If you’re exposing /graphql from WordPress, CORS deserves a deliberate setup. WPGraphQL makes WordPress feel like an app backend, which means browsers start enforcing cross-origin rules in ways a normal PHP theme never had to care about. ...

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

Capacitor sits in an awkward but very practical place: your app looks like a website, runs in a WebView, but ships like a native app. That hybrid setup changes how CORS behaves, and a lot of advice written for regular websites breaks down fast. If you’ve ever thought: “My API works in Chrome but not in Capacitor” “Why is my app origin capacitor://localhost?” “Why do cookies disappear on mobile?” “Why does native HTTP magically bypass CORS?” You’re in the right place. ...

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

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