What is CORS (Cross-Origin Resource Sharing)?

CORS is a browser mechanism that lets a server declare which other origins may call it, relaxing the same-origin policy on purpose. Two reframes dissolve most of the confusion: the browser enforces it (not the server, which is why curl works), and the server fixes it (not your frontend, which is why no amount of JavaScript helps). Everything else is headers.

Key takeaways

The whole protocol, on the wire

# Preflight: the browser asks before a PUT with an auth header
OPTIONS /classes/Product HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: x-parse-session-token

# The server's permission slip
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com   ← this origin may read
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: x-parse-session-token
Access-Control-Max-Age: 86400        ← cache this answer; skip tomorrow's preflight

# Then, and only then, the real request flies.

What it looks like from application code — and the platform truth the tabs teach: CORS is a browser concern, which native apps never meet:

// Browser JavaScript — Back4app JS SDK
// A cross-origin call that just works: the platform answers the
// preflight and sends the CORS headers, so the browser lets it through
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com'; // different origin than your site

const products = await new Parse.Query('Product').find();
// No proxy hacks, no "disable CORS" — the server side is configured correctly.

// Flutter / Dart — Back4app Flutter SDK
// Native apps have no same-origin policy — CORS is a browser concern.
// Flutter Web, however, DOES enforce it: same browser rules apply there.
final query = QueryBuilder<ParseObject>(ParseObject('Product'));
final response = await query.query();
// Works identically on mobile and web because the server sends CORS headers.

// iOS / Swift — Back4app Swift SDK
// No browser, no same-origin policy: CORS never applies to native iOS.
// The same backend serves browsers (with CORS headers) and apps alike.
let query = Product.query()
query.find { result in
  if case .success(let products) = result { render(products) }
}

// Android / Kotlin — Back4app Android SDK
// No browser, no same-origin policy: CORS never applies to native Android.
// The same backend serves browsers (with CORS headers) and apps alike.
val query = ParseQuery.getQuery<ParseObject>("Product")
query.findInBackground { products, e ->
  if (e == null) render(products)
}

The flow, decided

Two details carry most debugging sessions: a simple request (GET/HEAD/POST with safelisted headers and plain content types) skips the preflight — which is why adding an Authorization header suddenly “breaks” an endpoint that worked; and credentialed requests tighten everything — cookies flow only with Access-Control-Allow-Credentials: true plus an exact origin, never the wildcard, per the spec.

How to fix common CORS errors (error → cause → fix)

And the anti-fix worth naming: browser-flag disabling and permissive dev proxies make the error invisible on your machine only — the deploy still breaks for users. The real fix is a server configuration measured in minutes.

Common use cases

• SPA + API on different origins — app.example.com calling api.example.com: the everyday case CORS exists for.
• Local development — localhost:3000 against a real backend; allow the dev origin, don’t disable the shield.
• Public APIs — wildcard origin, no credentials: correct and safe for genuinely public data.
• Multi-frontend platforms — several apps, one backend, an explicit origin list per environment.
• BaaS backends — the platform answers preflights and sends the headers; your job reduces to declaring allowed origins.

Wildcard vs. explicit origins: a decision matrix

One security reframe closes the matrix: CORS is not access control — native apps and servers ignore it entirely, so it protects browser users from malicious sites, not your API from callers. Authentication and data-layer permissions do that job; CORS just decides which websites’ scripts may read the answers.

Limitations and trade-offs

• It only governs browsers. Anything non-browser walks past it — never mistake an origin list for authorization.
• Preflights cost a round trip on non-simple requests; Access-Control-Max-Age caching is the cheap, forgotten fix.
• Misconfiguration fails closed and loud — good for safety, brutal for debugging without the error→fix table above.
• Origin lists are environment state. Staging origins leak into production configs; audit the list like any credential.
• CORS ≠ CSRF ≠ CSP. Neighboring acronyms, separate defenses — cookies still need SameSite/token protection, and pages still need a content policy, with CORS handling only the cross-origin read.

CORS on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The CORS chore ships handled: platform APIs answer preflights and send correct headers, so browser apps call the backend from allowed origins without proxy hacks — the JavaScript tab above is the entire experience — while the Flutter, Swift, and Kotlin tabs demonstrate the quieter truth that native clients never meet the ceremony at all. Real security stays where it belongs: sessions, ACLs, and class-level permissions enforced server-side on every request, from every origin.