Was ist CORS (Cross-Origin Resource Sharing)?

CORS ist ein Browser-Mechanismus, mit dem ein Server erklärt, welche anderen Origins ihn aufrufen dürfen – eine bewusste Lockerung der Same-Origin-Policy. Zwei Umdeutungen lösen den größten Teil der Verwirrung auf: Der Browser setzt es durch (nicht der Server – deshalb funktioniert curl), und der Server behebt es (nicht Ihr Frontend – deshalb hilft kein noch so gutes JavaScript). Alles andere sind Header.

Das Wichtigste in Kürze

Das ganze Protokoll, auf der Leitung

# Preflight: Der Browser fragt vor einem PUT mit Auth-Header nach
OPTIONS /classes/Product HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: x-parse-session-token

# Der Erlaubnisschein des Servers
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com   ← diese Origin darf lesen
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: x-parse-session-token
Access-Control-Max-Age: 7200         ← Antwort cachen; keine wiederholten Preflights

# Dann, und erst dann, geht die eigentliche Anfrage raus.

Wie das aus dem Anwendungscode aussieht – und die Plattform-Wahrheit, die die Tabs vermitteln: CORS ist eine Sache des Browsers, der native Apps nie begegnen:

// 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)
}

Der Ablauf, entschieden

Zwei Details tragen die meisten Debugging-Sitzungen: Eine einfache Anfrage (GET/HEAD/POST mit Headern von der Safelist und einfachen Content-Types) überspringt den Preflight – deshalb bringt ein hinzugefügter Authorization-Header plötzlich einen Endpoint zum Scheitern, der vorher funktionierte; und Anfragen mit Credentials ziehen alles enger – Cookies fließen nur mit Access-Control-Allow-Credentials: true plus einer exakten Origin, nie mit dem Wildcard, so die Spezifikation.

Häufige CORS-Fehler beheben (Fehler → Ursache → Lösung)

Und die Anti-Lösung, die einen Namen verdient: Browser-Flags zum Abschalten und großzügige Dev-Proxys machen den Fehler nur auf Ihrer Maschine unsichtbar – für die Benutzer bleibt das Deployment kaputt. Die echte Lösung ist eine Serverkonfiguration, gemessen in Minuten.

Typische Anwendungsfälle

• SPA und API auf verschiedenen Origins – app.example.com ruft api.example.com auf: der Alltagsfall, für den es CORS gibt.
• Lokale Entwicklung – localhost:3000 gegen ein echtes Backend; lassen Sie die Dev-Origin zu, statt den Schutz abzuschalten.
• Öffentliche APIs – Wildcard-Origin, keine Credentials: korrekt und sicher für wirklich öffentliche Daten.
• Plattformen mit mehreren Frontends – mehrere Apps, ein Backend, eine explizite Liste von Origins pro Umgebung.
• BaaS-Backends – die Plattform beantwortet Preflights und schickt die Header; Ihre Aufgabe schrumpft darauf, die erlaubten Origins zu deklarieren.

Wildcard vs. explizite Origins: Entscheidungsmatrix

Eine sicherheitsbezogene Umdeutung schließt die Matrix ab: CORS ist keine Zugriffskontrolle – native Apps und Server ignorieren es vollständig, es schützt also Browser-Benutzer vor bösartigen Websites, nicht Ihre API vor Aufrufern. Diese Aufgabe erledigen Authentifizierung und Berechtigungen auf der Datenschicht; CORS entscheidet nur, welche Skripte welcher Websites die Antworten lesen dürfen.

Grenzen und Trade-offs

• Es regelt nur Browser. Alles, was kein Browser ist, geht daran vorbei – halten Sie eine Liste von Origins nie für Autorisierung.
• Preflights kosten einen Roundtrip bei nicht einfachen Anfragen; das Caching über Access-Control-Max-Age ist die billige, vergessene Lösung.
• Fehlkonfiguration scheitert geschlossen und laut – gut für die Sicherheit, brutal für das Debuggen ohne die Tabelle Fehler → Lösung von oben.
• Listen von Origins sind Umgebungszustand. Staging-Origins sickern in Produktionskonfigurationen; auditieren Sie die Liste wie jedes andere Credential.
• CORS ≠ CSRF ≠ CSP. Benachbarte Abkürzungen, getrennte Abwehrmechanismen – Cookies brauchen weiterhin SameSite- oder Token-Schutz, Seiten weiterhin eine Content-Policy, während CORS allein den Lesezugriff über Origin-Grenzen hinweg regelt.

CORS mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Pflichtaufgabe CORS kommt erledigt mit: Die Plattform-APIs beantworten Preflights und schicken korrekte Header, sodass Browser-Apps das Backend von erlaubten Origins aus ohne Proxy-Tricks aufrufen – der JavaScript-Tab oben ist bereits die ganze Erfahrung –, während die Tabs für Flutter, Swift und Kotlin die stillere Wahrheit zeigen: Native Clients begegnen der Zeremonie überhaupt nie. Die echte Sicherheit bleibt, wo sie hingehört: Sessions, ACLs und Klassenberechtigungen, serverseitig bei jeder Anfrage durchgesetzt, von jeder Origin aus.