CORS‑Fehler nach der Bereitstellung: Ursachen und Lösungen

Warum CORS nach der Bereitstellung plötzlich fehlschlagen kann

CORS ist eine Browser‑Regel, keine Server‑Regel. Ihr Frontend‑JavaScript läuft im Browser‑Tab, und der Browser entscheidet, ob er eine Antwort von einer anderen Origin (Domain, Protokoll oder Port) lesen darf. Wenn Ihr Backend nicht die richtigen CORS‑Header zurücksendet, blockiert der Browser die Antwort, auch wenn der Server tatsächlich Daten gesendet hat.

Darum wirken CORS‑Fehler nach der Bereitstellung verwirrend: Im Code hat sich vielleicht nichts geändert, aber die Origin hat sich. Lokal rufen Sie vielleicht http://localhost:5173 von http://localhost:3000 auf. Nach dem Deployment wird daraus etwas wie https://app.yourdomain.com, das https://api.yourdomain.com aufruft. Unterschiedliche Domains, HTTPS und manchmal andere Ports bedeuten unterschiedliche Origins, also prüft der Browser die Berechtigungen erneut.

Häufige Symptome sehen so aus:

• „Blocked by CORS policy“, obwohl die API in Postman oder curl funktioniert
• Eine Preflight‑(OPTIONS‑)Anfrage schlägt fehl, bevor die eigentliche Anfrage ausgeführt wird
• CORS‑Header fehlen bei Fehlern (401/403/500), daher schlägt es nur bei Fehlern fehl
• Anfragen mit Cookies funktionieren plötzlich nicht mehr

Deployment bringt auch unsichtbare Bausteine mit. Ein Reverse‑Proxy, CDN oder Plattform‑Setting kann Header überschreiben, entfernen oder eine falsche Version cachen. Der Wechsel zu HTTPS kann das Cookie‑Verhalten (SameSite und Secure) ändern und damit „credentials“‑Anfragen beeinflussen.

Ein realistisches Beispiel: Ihr Frontend beginnt in Produktion fetch(..., { credentials: 'include' }) zu senden, um Nutzer angemeldet zu halten. Wenn das Backend mit Access-Control-Allow-Origin: * antwortet, lehnt der Browser die Antwort ab, weil Wildcard‑Origins nicht mit Credentials verwendet werden dürfen.

Wenn Sie ein KI‑generiertes Frontend‑Backend‑Setup geerbt haben, sind solche Missmatches häufig. Bei FixMyMess ist der schnellste Gewinn meist, die deployte Origin zu verifizieren und dann sicherzustellen, dass jeder Antwortpfad (einschließlich Fehler) konsistente CORS‑Header liefert.

Preflight 101: die OPTIONS‑Anfrage, die Sie nicht bemerkt haben

Viele CORS‑Fehler nach der Bereitstellung betreffen gar nicht den eigentlichen API‑Aufruf. Der Browser schickt oft vorher eine stille „Preflight“‑Anfrage. Das ist eine OPTIONS‑Anfrage, die den Server fragt: „Wenn ich diese echte Anfrage von dieser Origin sende, erlaubst du sie?“

Einfache vs. preflight‑pflichtige Anfragen

Einige Anfragen sind „einfach“ und überspringen Preflight. Viele moderne Frontend‑Aufrufe sind nicht einfach, daher preflightet der Browser.

Preflight wird ausgelöst durch Dinge wie:

• Methoden außer GET/POST/HEAD (z. B. PUT, PATCH, DELETE)
• Das Senden von JSON mit Content-Type: application/json
• Jegliche benutzerdefinierte Header (wie Authorization, X-Requested-With oder X-Api-Key)
• Verwendung von fetch‑Optionen, die Header hinzufügen, die Sie nicht erwartet haben

Das bedeutet: Sie können den Endpunkt direkt aufrufen und „200 OK“ sehen, trotzdem blockiert der Browser den Aufruf. Warum? Weil der Browser beim OPTIONS‑Schritt scheitert. Wenn OPTIONS 404, 401, 500 oder fehlende CORS‑Header zurückgibt, wird die echte Anfrage nie gesendet.

Warum Redirects oft Preflight brechen

Ein häufiger, nur in Produktion auftretender Fehler ist ein unerwarteter Redirect bei OPTIONS. Zum Beispiel könnte Ihre API HTTP zu HTTPS weiterleiten, www hinzufügen/entfernen oder unauthentifizierte Anfragen an eine Login‑Route schicken. Browser gehen mit Redirects bei Preflight schlecht um; viele behandeln es als Fehler, selbst wenn die weitergeleitete URL funktionieren würde.

Ein praktisches Beispiel: Ihr Frontend auf https://app.example.com ruft https://api.example.com auf. Die API ist in Ordnung, aber OPTIONS zu /v1/data liefert einen 301 zu /v1/data/ (trailing slash). Ihr GET kann in Tests noch funktionieren, aber der Browser blockiert es, weil Preflight keine saubere CORS‑zugelassene Antwort erhalten hat.

Die Lösung ist meist: Stellen Sie sicher, dass OPTIONS direkt Erfolg zurückgibt (oft 204 oder 200), dieselben CORS‑Header wie echte Antworten enthält und niemals weiterleitet.

Origins: was übereinstimmen muss, und was oft falsch verstanden wird

Viele CORS‑Fehler nach der Bereitstellung entstehen, weil die erlaubte Origin, die Sie konfiguriert haben, nicht der exakten Zeichenfolge entspricht, die der Browser sendet.

Wichtiges Missverständnis ist Origin vs Host. Ihr Server erhält einen Host‑Header (wohin die Anfrage geht) und der Browser sendet einen Origin‑Header (wo die Seite gehostet ist, die die Anfrage macht). CORS‑Entscheidungen basieren auf Origin, nicht auf Host.

Eine Origin ist nicht nur eine Domain. Sie ist ein genaues Trio: Schema + Domain + Port.

Exaktes Origin‑Matching (Schema, Domain, Port)

Wenn Ihr Frontend unter https://app.example.com läuft und Ihre API https://api.example.com ist, sendet der Browser Origin: https://app.example.com. Ihr Backend muss mit Access-Control-Allow-Origin: https://app.example.com antworten (oder eine serverseitige Allowlist, die genau diesen Wert liefert).

http vs https ist die klassische Falle beim Deployment. Lokal testen Sie vielleicht von http://localhost:3000. Nach dem Deployment wird die Seite https://... und Ihre Allowlist enthält weiterhin nur die http‑Version, also blockiert der Browser.

Häufige Abweichungen, die Sie prüfen sollten

Prüfen Sie auf diese kleinen Unterschiede, die CORS brechen können:

• https://example.com vs. https://www.example.com
• Ein fehlender Port: https://example.com vs. https://example.com:8443
• Staging‑Domains: https://staging.example.com vs. https://app.example.com
• Unerwartete lokale Origins: http://127.0.0.1:3000 vs. http://localhost:3000
• Mobile oder Preview‑Builds, die eine andere Domain als Produktion nutzen

Ein reales Szenario: Ihr Frontend wird von https://www.brand.com ausgeliefert, aber Sie haben nur https://brand.com erlaubt. Für Menschen sieht das ähnlich aus, für den Browser ist es eine andere Origin.

Wenn Sie ein KI‑generiertes Backend übernommen haben, enthält es oft eine hartkodierte Origin‑Liste, die für die Live‑Domain nie aktualisiert wurde. FixMyMess beginnt typischerweise damit, die tatsächlichen Origin‑Werte in Produktions‑Logs zu lesen und dann die Allowlist genau darauf abzustimmen.

CORS‑Antwortheader, die jedes Mal korrekt sein müssen

CORS ist keine einmalige Einstellung. Der Browser prüft bei jeder Cross‑Origin‑Anfrage bestimmte Antwortheader und ist streng dabei. Fehlt ein Header auf nur einer Route (oft der OPTIONS‑Route), können CORS‑Fehler auftreten, die zufällig wirken.

Der Browser möchte vor allem wissen: Ist meine Origin erlaubt, und sind für diese Anfrage Methode und Header erlaubt? Das heißt, Ihre API muss Access-Control-Allow-Origin zurückgeben, das mit der anfragenden Origin übereinstimmt (z. B. https://app.example.com). Wenn Sie die falsche Origin zurückgeben oder sie auf einigen Endpunkten vergessen, blockiert der Browser die Antwort, selbst wenn der Server 200 zurückgegeben hat.

Preflight‑Fehler kommen häufig von Access-Control-Allow-Headers. Die Preflight‑Anfrage enthält Access-Control-Request-Headers mit dem, was der Browser senden möchte. Wenn Ihre Antwort nicht jeden dieser Header enthält (häufige Auslassungen: Authorization, Content-Type, X-Requested-With), stoppt der Browser vor der echten Anfrage.

Caching kann CORS ebenfalls inkonsistent erscheinen lassen. Wenn Sie mehrere Origins erlauben, fügen Sie Vary: Origin hinzu, damit CDNs und Proxies nicht die CORS‑Antwort einer Origin cachen und später einer anderen Origin servieren.

Für OPTIONS‑Preflight ist 204 No Content in Ordnung, aber die Header müssen trotzdem vorhanden sein. Eine saubere Preflight‑Antwort enthält üblicherweise:

• Access-Control-Allow-Origin
• Access-Control-Allow-Methods (nehmen Sie die Methoden auf, die Sie verwenden, z. B. GET, POST, PATCH)
• Access-Control-Allow-Headers (decken Sie ab, was der Browser angefragt hat)
• Vary: Origin
• Optional: Access-Control-Max-Age, um wiederholte Preflights zu reduzieren

Ein praktischer Tipp: Stellen Sie sicher, dass Ihre CORS‑Middleware vor Routing, Auth‑Checks und Error‑Handlern läuft. Andernfalls können 401/403/500‑Antworten ohne CORS‑Header zurückgegeben werden und verwirrende „CORS blocked“‑Meldungen auslösen, die in Wirklichkeit Auth‑ oder Serverfehler sind.

Credentials und Wildcards: die häufigste Produktionsfalle

Viele CORS‑Fehler nach der Bereitstellung entstehen durch eine Regel, die man oft erst in Produktion lernt: Sie können Credentials nicht mit einem Wildcard‑Origin kombinieren.

Wenn der Browser Cookies sendet (oder Sie ihm sagen, er soll Credentials senden), muss der Server mit einer konkreten Origin antworten, nicht mit *. Das schlägt also fehl:

• Access-Control-Allow-Origin: *
• Access-Control-Allow-Credentials: true

Cookies vs. Authorization: warum sie sich unterschiedlich verhalten

Cookies werden automatisch vom Browser angehängt, daher werden sie streng kontrolliert. Wenn Ihr Frontend und Ihre API auf unterschiedlichen Domains liegen, werden Cookies nicht gesendet, es sei denn, Sie aktivieren sie im Frontend und erlauben sie im Backend.

Ein Authorization: Bearer ...‑Header ist anders. Er hängt nicht von Cookies ab, löst aber oft ein Preflight aus, weil er kein einfacher Header ist. Das kann trotzdem fehlschlagen, aber die „Wildcard + Credentials“‑Falle betrifft in der Regel Cookies.

Im Frontend ändert diese eine Zeile die ganze Anforderung:

fetch("https://api.example.com/me", {
  credentials: "include"
})

Sobald Sie credentials: "include" (oder withCredentials: true in Axios) hinzufügen, lehnt der Browser Antworten ab, wenn das Backend nicht sehr explizit ist.

Was das Backend jedes Mal senden muss

Stellen Sie sicher, dass Ihre API‑Antworten enthalten:

• Access-Control-Allow-Origin: https://your-frontend.com (exakte Übereinstimmung)
• Access-Control-Allow-Credentials: true
• Vary: Origin (damit Caches Origins nicht vermischen)

Beispiel: Lokal rufen Sie http://localhost:3000 zu http://localhost:8000 auf und es funktioniert. In Produktion wechseln Sie zu https://app.yourdomain.com und verwenden Cookies für Logins. Wenn Ihr Server weiterhin Access-Control-Allow-Origin: * zurückgibt, blockiert der Browser die Antwort, auch wenn die API 200 liefert.

Wenn Sie KI‑generierten Backend‑Code übernommen haben, ist diese Fehlkonfiguration häufig. FixMyMess findet oft die richtigen Header in einer Route, aber sie fehlen bei Auth‑Refresh oder Fehlerantworten, was den Bug zufällig erscheinen lässt.

Proxies, CDNs und Plattform‑Konfiguration, die Ihre App überschreiben

CORS‑Fehler nach der Bereitstellung treten oft auf, weil Ihr Frontend nicht mehr direkt mit Ihrem App‑Server spricht. Ein Reverse‑Proxy, Load‑Balancer, CDN oder eine Plattform‑Sicherheits‑Schicht kann Anfragen und Antworten so verändern, wie es Ihr lokales Setup nie tat.

Wenn der Edge Ihre Header ändert

Viele Proxies können Header hinzufügen, entfernen oder duplizieren. Wenn Ihre App die richtigen Access-Control-Allow-Origin zurückgibt, der Proxy ihn aber überschreibt (oder einen zweiten hinzufügt), können Browser die Antwort ablehnen. Ein anderes stilles Problem: Der Proxy komprimiert oder leitet Antworten anders weiter, und die Redirect‑Antwort fehlt CORS‑Header, obwohl der finale Endpunkt korrekt ist.

Ein häufiger, nur in Produktion auftretender Fehler ist, dass OPTIONS‑Anfragen nie Ihre App erreichen. Manche Plattformen behandeln OPTIONS als verdächtig, blockieren sie per Firewall oder routen sie zu einem Default‑Handler, der 404/405 ohne CORS‑Header zurückgibt. Aus Browser‑Sicht sieht das wie „CORS ist kaputt“ aus, der echte Grund ist aber Routing.

CDN‑Caching kann falsche CORS‑Header ausliefern

Wenn ein CDN API‑Antworten cached, ohne nach Origin zu unterscheiden, kann es versehentlich eine Antwort mit CORS‑Headern für eine andere Site ausliefern. Beispiel: Nutzer A ruft Ihre API von https://app.example.com auf und das CDN cached die Antwort mit dieser Origin. Nutzer B ruft dieselbe URL von https://admin.example.com auf und erhält die gecachte Header‑Antwort, die nicht passt – der Browser blockiert sie.

Hier ist, was Sie der Reihe nach prüfen sollten:

• Prüfen Sie die Response‑Header an der Edge (CDN/Proxy) und am App‑Server und bestätigen Sie, dass sie übereinstimmen.
• Bestätigen Sie, dass OPTIONS‑Anfragen erlaubt und zur App geroutet werden, nicht blockiert oder von einer Default‑Regel behandelt.
• Stellen Sie sicher, dass Redirects (http zu https, apex zu www) ebenfalls CORS‑Header zurückgeben.
• Wenn Caching beteiligt ist, sorgen Sie dafür, dass Antworten nach Origin variieren oder deaktivieren Sie das Caching für API‑Routen.
• Vergleichen Sie Staging‑ vs. Produktions‑Proxy‑Regeln Zeile für Zeile.

Wenn Sie KI‑generierten Backend‑Code übernommen haben, ist diese Diskrepanz in der Proxy‑Schicht häufig die Ursache – die App „sieht richtig aus“, aber die Edge‑Konfiguration ist stillschweigend anders. FixMyMess findet solche Probleme oft bei einem Code‑Audit.

Umgebungsvariablen und Allowlists: stille Bruchstellen

CORS‑Fehler nach der Bereitstellung führen oft auf eine langweilige Änderung zurück: Ihr Frontend ruft jetzt eine andere URL auf, als Sie denken. Lokal kann ein Dev‑Server Anfragen proxyen und das Problem verbergen. In Produktion spricht der Browser direkt mit der API, sodass jede Abweichung sofort auffällt.

Ein häufiger Fehler ist, das Frontend mit der falschen API‑Basis‑URL zu bauen. Beispielsweise nimmt Ihr Build API_URL=https://staging-api... (oder eine alte Preview‑URL), weil die Produktions‑Umgebungsvariable nicht gesetzt wurde oder das Hosting eine frühere Build‑Version gecached hat. Der Browser sendet dann Anfragen von Ihrer Live‑Domain an eine Staging‑API, die diese Origin nicht erlaubt.

Eine weitere stille Fehlerquelle ist die Backend‑Allowlist. Teams fügen http://localhost:3000 während der Entwicklung hinzu und vergessen, die echte Domain später einzutragen. Es wird schlimmer bei mehreren Domains: www vs. ohne www, eine Marketing‑Domain, ein App‑Subdomain und eine Preview‑Domain. Fehlt auch nur eine Origin, funktioniert diese Umgebung „zufällig“ nicht.

Um Drift zu vermeiden, zentralisieren Sie Ihre erlaubten Origins und behandeln Sie sie als echte Konfigurations‑Surface, nicht als verstreute Strings.

Praktischer Weg, Konfigurationsdrift zu verhindern

Halten Sie die Regeln an einem Ort und machen Sie sie strikt:

• Verwenden Sie eine Umgebungsvariable für erlaubte Origins (kommagetrennt), die beim Start geparst wird.
• Normalisieren Sie Domains (inklusive exaktem Schema und Host, z. B. https://app.example.com).
• Pflegen Sie getrennte Werte für Dev, Staging und Produktion und dokumentieren Sie, welche Frontend‑URL auf welche API zeigt.
• Loggen Sie die aufgelöste Allowlist beim Start (und den Origin bei CORS‑Fehlern).
• Fügen Sie nach jedem Deploy einen schnellen Smoke‑Test von der realen Domain hinzu.

Wenn Sie KI‑generierten Code geerbt haben, ist dies eine häufige FixMyMess‑Diagnose: Das Frontend zeigt auf eine Umgebung, während die Backend‑CORS‑Konfiguration eine andere hat, und niemand bemerkt es bis zum ersten Live‑Deploy.

Eine reproduzierbare CORS‑Fix‑Strategie (Schritt für Schritt)

Wenn CORS‑Fehler nach der Bereitstellung auftreten, behandeln Sie es wie Debugging, nicht als Ratespiel. Ziel ist es, die genaue Anfrage zu finden, die der Browser blockiert, und den fehlenden bzw. inkorrekten Header zu identifizieren.

Starten Sie in den DevTools Ihres Browsers im Netzwerk‑Tab. Filtern Sie nach dem fehlschlagenden API‑Aufruf und schauen Sie nach einer OPTIONS‑Anfrage unmittelbar davor. Wenn Sie OPTIONS sehen, handelt es sich um Preflight. Wenn nicht, liegt der Fehler meist bei der echten Anfrage (oft ein fehlender Header bei einer 401/500‑Antwort).

Verwenden Sie diese Reihenfolge und überspringen Sie keine Schritte:

1. Reproduzieren und erfassen Sie die fehlerhafte Anfrage: kopieren Sie die Request‑Details aus dem Netzwerk‑Tab, inklusive Methode, URL, Statuscode und ob ein OPTIONS‑Preflight stattgefunden hat.
2. Bestätigen Sie die exakte Origin: lesen Sie den Origin‑Request‑Header und notieren Sie ihn genau (Schema + Domain + Port). Viele „es passt“‑Probleme sind in Wirklichkeit http vs https oder www vs ohne www.
3. Prüfen Sie Header in beiden Antworten: öffnen Sie die OPTIONS‑Antwort und die echte Antwort. Beide müssen die richtigen CORS‑Header enthalten (insbesondere Access-Control-Allow-Origin, und für Cookies: Access-Control-Allow-Credentials).
4. Beseitigen Sie Redirects und Middleware‑Überraschungen: wenn die API umleitet (301/302) oder einen Slash erzwingt, scheitert Preflight oft, weil die umgeleitete Antwort keine CORS‑Header hat. Lassen Sie OPTIONS direkt 200/204 mit den Headern antworten.
5. Wechseln Sie von * zu einer expliziten Allowlist: legen Sie für Produktion eine kurze Liste erlaubter Origins fest, testen Sie neu und fügen Sie nur das hinzu, was wirklich nötig ist.

Ein kurzer Check: Wenn Sie Cookies oder Auth verwenden, dürfen Sie nicht Access-Control-Allow-Origin: * einsetzen. Sie müssen eine spezifische Origin echoen und Credentials erlauben.

Wenn Ihr Backend von einem KI‑Tool generiert wurde und die CORS‑Logik über Routen, Proxies und Plattform‑Einstellungen verstreut ist, kann FixMyMess die einzige Quelle der Wahrheit ermitteln und sie nach einer kostenlosen Code‑Überprüfung sicher patchen.

Häufige Fehler, die CORS kaputt halten

Viele CORS‑Fehler nach der Bereitstellung sind selbstverschuldet. Lokal sieht alles gut aus, weil Sie auf einer Origin sind, einfache Anfragen nutzen und Ihr Dev‑Server nachsichtig ist. Produktion ist strenger: andere Domains, HTTPS, Cookies und oft ein Proxy oder CDN davor.

Hier die Fehler, die am häufigsten auftreten, wenn ein Frontend mit einem separaten Backend spricht:

• Während der Entwicklung jede Origin erlauben und dann in Produktion Cookies/Auth aktivieren, ohne CORS anzupassen (* + Credentials geht nicht).
• CORS‑Header nur auf dem Happy‑Path hinzufügen, nicht bei 401/403/500‑Antworten, sodass der Browser den echten Fehler hinter einer CORS‑Meldung verbirgt.
• Vergessen, dass der Browser bei vielen Anfragen ein OPTIONS‑Preflight sendet und Ihr Server/Router/Middleware diese nicht mit den gleichen CORS‑Headern beantwortet.
• Auf Framework‑Defaults (oder kopierte CORS‑Snippets) vertrauen, ohne die tatsächlichen Antwort‑Header in Produktion zu prüfen.
• Versuchen, das Problem im Frontend durch fetch/axios‑Settings zu beheben, obwohl CORS vom Browser durchgesetzt wird und auf dem Server gelöst werden muss.

Eine leicht zu übersehende Falle: Sie fügen Access-Control-Allow-Origin für GET /api/me hinzu, aber Ihre Auth‑Schicht blockiert die Anfrage früh. Die 401‑Antwort enthält keine CORS‑Header, also meldet der Browser einen CORS‑Fehler statt „unauthorized“. Es wirkt, als sei CORS kaputt; der eigentliche Fehler ist fehlende CORS‑Header bei Fehlern.

Eine weitere Falle ist, Credentials und Wildcards zu mischen. Wenn Ihr Frontend Cookies (oder Authorization‑Header) verwendet und Sie withCredentials: true gesetzt haben, muss das Backend eine spezifische Origin (z. B. https://app.example.com) zurückgeben und Credentials erlauben. * wird fehlschlagen.

Wenn Sie KI‑generierten Code geerbt haben, sind diese Probleme oft über Middleware, Serverless‑Funktionen und Reverse‑Proxies verstreut. FixMyMess sieht regelmäßig Projekte, in denen CORS an einer Stelle „gesetzt“ ist, aber irgendwo anders überschrieben wird. Der schnellste Weg ist, echte Produktions‑Antworten für OPTIONS und die finale Anfrage zu prüfen, inklusive Fehlerfälle.

Beispiel: Frontend funktioniert lokal, bricht auf der Live‑Domain

Eine typische Geschichte: Sie haben eine React‑App auf http://localhost:3000 und eine API auf http://localhost:8080. Sie loggen sich ein, die API setzt ein Cookie und jede Anfrage funktioniert.

Dann deployen Sie. Die React‑App liegt unter https://app.yourdomain.com, die API unter https://api.yourdomain.com, und plötzlich sehen Sie CORS‑Fehler nach der Bereitstellung. Das Verwirrende ist: Der Code hat sich nicht geändert.

Was sich tatsächlich geändert hat, sind die Browser‑Regeln. Cross‑Site‑Cookies und Preflight‑Prüfungen sind auf echten HTTPS‑Origins strenger. Lokal lösen Sie vielleicht kein Preflight aus, oder Ihr Dev‑Server proxyt Anfragen leise, sodass der Browser nie eine Cross‑Origin‑Anfrage sieht.

Das typischerweise zur Lösung dieses Setups:

• Setzen Sie Access-Control-Allow-Origin auf die exakte Frontend‑Origin (https://app.yourdomain.com), nicht auf *.
• Setzen Sie Access-Control-Allow-Credentials: true sowohl in der Preflight‑(OPTIONS) als auch in der echten Antwort.
• Sorgen Sie dafür, dass Ihr Server für dieselbe Route auf OPTIONS mit 200/204 und den gleichen CORS‑Headern antwortet.
• Senden Sie Cookies aktiv vom Frontend (für fetch: credentials: "include"; für Axios: withCredentials: true).
• Stellen Sie sicher, dass Cookies für Cross‑Site‑Anfragen geeignet sind (häufig SameSite=None; Secure).

Wie Sie die Lösung in Produktion bestätigen: Öffnen Sie DevTools Network, finden Sie die fehlschlagende Anfrage und prüfen Sie zwei Einträge. Erstens sollte der OPTIONS‑Preflight Erfolg zurückgeben und Access-Control-Allow-Origin und Access-Control-Allow-Credentials enthalten. Zweitens sollte die echte API‑Antwort dieselben Header zurückgeben und das Cookie setzen/versenden.

Wenn ein KI‑generiertes Backend inkonsistent ist (OPTIONS von einer Schicht, die echte Anfrage von einer anderen behandelt), findet FixMyMess solche Mismatches oft schnell bei einem Code‑Audit und patcht sie sicher.

Kurze Checkliste und nächste Schritte

Wenn Sie CORS‑Fehler nach der Bereitstellung sehen, behandeln Sie es als Header‑Abgleich‑Problem, nicht als Mysterium. Beginnen Sie damit, zu prüfen, was der Browser tatsächlich auf der fehlerhaften Anfrage erhalten hat und (falls vorhanden) die Preflight‑Antwort.

Hier schnelle Prüfungen, die die meisten Real‑World‑Probleme aufdecken:

• Bestätigen Sie, dass die Origin exakt mit dem übereinstimmt, was der Server erlaubt (Schema + Domain + Port). https://app.com und https://www.app.com sind unterschiedliche Origins.
• Wenn Sie Cookies oder Auth senden, stellen Sie sicher, dass die Credentials‑Regeln korrekt sind: die Antwort muss Access-Control-Allow-Credentials: true enthalten und die Origin darf nicht * sein.
• Öffnen Sie das Netzwerk‑Panel und prüfen Sie den OPTIONS‑Preflight: er sollte einen Erfolgscode (typisch 200 oder 204) mit denselben CORS‑Headern wie die reale Anfrage zurückgeben.
• Verifizieren Sie, dass Access-Control-Allow-Headers das enthält, was Sie tatsächlich senden (häufige Auslassungen: Authorization, Content-Type, X-Requested-With).
• Stellen Sie sicher, dass der Preflight nicht weitergeleitet wird (301/302). Redirects entstehen oft durch HTTP zu HTTPS oder einen fehlenden Trailing Slash.

Wenn das alles richtig aussieht, das Problem aber weiterhin besteht, liegt die Ursache oft eine Schicht über Ihrem Code: ein Proxy, CDN oder Plattform, die Header umschreibt, eine alte Antwort cached oder OPTIONS anders beantwortet.

Nächste Schritte, um das dauerhaft zu verhindern:

• Schreiben Sie die erlaubten Origins pro Umgebung (lokal, staging, Produktion) auf und halten Sie sie in der Konfiguration, nicht verstreut in Dateien.
• Fügen Sie einen einfachen Integrationstest hinzu, der gegen die deployte Domain läuft und die Preflight‑Response‑Header verifiziert.
• Entscheiden Sie sich für eine Auth‑Strategie (Cookies oder Tokens) und stimmen Sie CORS‑ und Session‑Einstellungen darauf ab.
• Loggen Sie OPTIONS‑Anfragen in Produktion, zumindest temporär, damit Sie Statuscodes und Header sehen.

Wenn Ihre App von Tools wie Lovable, Bolt, v0, Cursor oder Replit generiert wurde und die CORS‑Konfiguration über Backend‑Code und Deploy‑Einstellungen verteilt ist, kann FixMyMess einen kostenlosen Code‑Audit durchführen und Backend‑Header und Platform‑Config schnell zusammenbringen.