Your single-page app is served from one origin and its API from another, and calls carry the user's session. How would you decide between keeping that cross-origin arrangement with CORS and serving the API from the app's own origin through a reverse proxy path such as /api?

## Frame the decision, do not default This is a boundary question, not a CORS-configuration question. The real inputs are: how many independent clients the API has, what carries authentication, who operates the edge, and how many origins the frontend is deployed to. CORS is a mechanism for letting *other people's* origins read your responses. Using it to let your own app talk to your own API is legal but is often paying a security and latency price for a separation you did not need. ## What same-origin proxying buys Route `https://app.example.com/api/*` at the edge to the upstream service and the browser sees same-origin requests. That erases several categories of problem at once: - **No permission checks, ever.** Requests with JSON bodies, `Authorization` headers, `PATCH` and `DELETE` all go straight out. On a chatty API over a high-latency mobile link, removing an extra round trip per non-simple request is a measurable win that no CORS tuning can match. - **First-party cookies.** A same-origin session cookie is not a cross-site cookie: it needs no `SameSite=None`, it is not exposed to third-party cookie restrictions, and it does not sit in the category browsers are actively tightening. You stop betting your login flow on a moving target. - **One less permissive surface.** No allow-list of origins to maintain, no risk that a reflection rule ships without its check, no divergence between environments. - **A simpler failure vocabulary.** Failures become statuses your code can read instead of console messages your code cannot. ## What it costs - **A hop you own.** The proxy is now in the request path for every API call: it needs capacity, timeouts, health checks, tracing and a deploy story. If the frontend is served from a static host or a CDN with limited rewrite capability, this may be a real constraint rather than a config line. - **Behaviour to verify.** Streaming responses, server-sent event connections, large uploads, and long-lived requests all behave differently through an intermediary that buffers. Test them explicitly rather than assuming transparency. - **A merged blast radius.** Same origin means the API and the app share cookies, storage and script context. A cross-site scripting flaw anywhere in the app is already same-origin with the API — although in practice a cross-origin arrangement with a credentialed allow-list is barely better, since the compromised page is on the list. - **A local-development illusion.** A dev-server proxy makes everything same-origin locally, which silently hides cross-origin problems until staging. If production is cross-origin, development should be too. ## When cross-origin with CORS is the right answer - **The API is a product.** Third-party developers, partner integrations, or public documentation mean the API must serve origins you do not control. That is exactly what CORS is for. - **Many first-party origins.** Several apps, white-label domains, or per-customer subdomains that all call one API. Proxying each one duplicates the edge; an allow-list centralises the decision. - **Token-based auth.** If callers send a bearer token in an `Authorization` header rather than relying on a cookie, nothing ambient is attached, credentialed-mode rules never engage, and the cross-site cookie question disappears. The remaining cost is one advance check per endpoint, amortised by the browser remembering the approval. - **Organisational reality.** If the API team and the frontend team ship independently and no one owns a shared edge, an explicit CORS contract may be the honest interface. ## The rules I hold either way 1. **Enumerate origins; never wildcard a credentialed endpoint.** If origins are computed, the computation is an allow-list lookup, not an echo of whatever arrived. 2. **Give preview deployments a deliberate mechanism.** Per-branch URLs are the usual reason a permissive pattern gets shipped. Either match them against a strict pattern in non-production only, or route previews through the same proxy the production app uses. 3. **Never treat CORS as authorization.** Every endpoint authenticates and authorizes on its own, because a non-browser client ignores CORS entirely and a cross-origin write can reach the server regardless. 4. **Make the choice reversible and observable.** Whichever way it goes, know how you would detect that browsers stopped attaching a cross-site cookie, or that the proxy started buffering a stream — the failure modes are quiet on both paths. ## How I would say it in one line A first-party SPA with a cookie session usually belongs on the same origin as its API; CORS is the right tool when the set of callers is genuinely open, and in that case the auth should not depend on ambient cookies.