CORS for Mobile App Backends: What Actually Matters

let url = URL(string: "https://api.example.com/v1/profile")!
var request = URLRequest(url: url)
request.setValue("Bearer \(token)", forHTTPHeaderField: "Authorization")

URLSession.shared.dataTask(with: request) { data, response, error in
    // Handle response
}.resume()

val request = Request.Builder()
    .url("https://api.example.com/v1/profile")
    .addHeader("Authorization", "Bearer $token")
    .build()

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(call: Call, e: IOException) {}
    override fun onResponse(call: Call, response: Response) {
        val body = response.body?.string()
    }
})

fetch("https://api.example.com/v1/profile", {
  headers: {
    Authorization: `Bearer ${token}`
  }
})
```text


If that code runs inside a `WKWebView` or Android `WebView`, the browser engine may enforce CORS just like Safari or Chrome would.

This surprises teams because they think “it’s inside our app, so it’s native.” It isn’t. If the request comes from browser JavaScript, CORS rules matter.

### 2. `Authorization` triggers preflight

Most authenticated API calls from browser-based clients send headers like:

- `Authorization`
- `Content-Type: application/json`

That often triggers a preflight `OPTIONS` request.

Browser sends:

Server must answer correctly:

If your server ignores `OPTIONS`, your browser client fails before the real request is even sent.

Native mobile clients won’t care. Browser clients absolutely will.

### 3. Teams confuse CORS with auth

CORS does **not** protect your API from unauthorized access.

If your API is public on the internet, anyone can call it from curl, a mobile app, a script, or a server, whether CORS allows browser access or not.

This is allowed by CORS:

But it does not mean only `app.example.com` can access the API. It only means browser JavaScript running on that origin can read the response.

Your actual protection still comes from:

- bearer tokens
- session validation
- API keys
- mTLS
- signed requests
- rate limiting

I’m blunt about this because I’ve seen people ship “secure” APIs with weak auth because they thought strict CORS was enough. It isn’t.

## A real-world header example

GitHub’s API is a good example of a public API making deliberate CORS choices. `api.github.com` returns:

Two useful takeaways:

1. `Access-Control-Allow-Origin: *` makes sense for a public API.
2. `Access-Control-Expose-Headers` is how browser code can read useful non-simple response headers like rate limit metadata.

Without `Access-Control-Expose-Headers`, your frontend can receive the response body but still be unable to read headers you care about.

Example:

```javascript
const res = await fetch("https://api.github.com/rate_limit");
console.log(res.headers.get("X-RateLimit-Remaining")); // works only if exposed

const express = require("express");
const cors = require("cors");

const app = express();

const allowedOrigins = new Set([
  "https://app.example.com",
  "https://admin.example.com"
]);

app.use(cors({
  origin(origin, callback) {
    // Allow non-browser requests with no Origin header
    if (!origin) return callback(null, true);

    if (allowedOrigins.has(origin)) {
      return callback(null, true);
    }

    return callback(new Error("Origin not allowed by CORS"));
  },
  methods: ["GET", "POST", "PUT", "PATCH", "DELETE", "OPTIONS"],
  allowedHeaders: ["Authorization", "Content-Type", "X-Request-Id"],
  exposedHeaders: ["ETag", "Link", "X-RateLimit-Remaining", "X-Request-Id"],
  credentials: false,
  maxAge: 600
}));

app.options("*", cors());

app.get("/v1/profile", (req, res) => {
  res.set("X-Request-Id", "req_123");
  res.set("X-RateLimit-Remaining", "42");
  res.json({ id: 1, name: "Ava" });
});

app.listen(3000);
```text


A few opinions here:

- I prefer explicit origin allowlists for private backends.
- I allow requests with no `Origin` header because native apps, curl, and server-to-server traffic commonly have none.
- I expose only headers clients actually need.
- I keep `credentials: false` unless I’m truly using cookies in the browser.

## Cookie-based auth changes the rules

If your browser client uses cookies, you cannot combine credentials with wildcard origin.

This is invalid for credentialed CORS:

You need a specific origin:

That `Vary: Origin` part matters for caches and CDNs. Skip it and you can serve the wrong CORS headers to the wrong origin.

If your mobile app uses bearer tokens and your web app also uses bearer tokens, life is simpler. Cookie auth in browser APIs is where CORS configs get messy fast.

## Nginx example for preflight handling

A lot of teams terminate traffic at Nginx and then wonder why `OPTIONS` breaks. Here’s a minimal pattern:

If you support multiple origins, don’t hardcode the wrong one everywhere. Reflecting origin dynamically can work, but only if you validate it against an allowlist first.

## Testing CORS without guessing

Don’t debug CORS by staring at app code and hoping.

Use:

- browser devtools network tab
- curl for raw headers
- a header inspection tool like [headertest.com](https://headertest.com)

Quick curl examples:

Preflight simulation:

That usually tells you exactly what’s broken in under a minute.

## Security headers around CORS

CORS is only one layer. If your backend also serves web content, look at the rest of your security headers too: CSP, HSTS, `X-Content-Type-Options`, and friends. If you need a reference for that side of things, [csp-guide.com](https://csp-guide.com) is useful.

But keep the boundaries clear:

- **CORS** controls which browser origins can read responses
- **CSP** controls what a page is allowed to load and execute
- **Auth** controls who can access data
- **TLS** protects transport

Different tools, different jobs.

## Rules I’d give any mobile backend team

1. Assume your API will eventually be called from a browser.
2. Don’t use CORS as a substitute for authentication.
3. Allow requests with no `Origin` header for native/server clients.
4. Handle `OPTIONS` cleanly.
5. Expose response headers your browser client genuinely needs.
6. Use explicit origins for private apps.
7. Use `*` only when the API is truly public and you mean it.
8. Be extra careful with cookies and `Access-Control-Allow-Credentials`.

If your backend is strictly native-only today, CORS might not matter yet. But “native-only” rarely lasts. Planning for browser access early saves a lot of ugly rewrites later.