CORS-Fehler beheben: Was „blocked by CORS policy“ bedeutet

Ihr Frontend läuft unter http://localhost:5173, Ihre API unter http://localhost:3001. In curl und Postman liefert die API JSON, im Browser aber wirft fetch() den Fehler TypeError: Failed to fetch, und die Konsole zeigt: Access to fetch at 'http://localhost:3001/api/products' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Dabei zeigt das Log der API, dass die Anfrage angekommen ist und mit 200 beantwortet wurde.

Im Folgenden: was ein Origin ist, warum der Browser die Antwort blockiert, einfache Anfragen im Vergleich zu Preflight-Anfragen, jede Chrome-Meldung, getestete Lösungen für Express, Flask und Vite, ein Weg über das Backend für APIs, die Ihnen nicht gehören, und warum Scraping-Code nie auf CORS stößt.

Was ist ein CORS-Fehler?#

Es ist der Browser, der sich weigert, Ihrem Skript eine Antwort zu übergeben. CORS, Cross-Origin Resource Sharing, ist ein Satz von HTTP-Antwort-Headern, mit denen ein Server dem Browser mitteilt, welche anderen Origins seine Antworten lesen dürfen. Der Fetch Standard legt das als Opt-in an, damit Daten hinter einer Firewall oder einem Login nicht von vornherein an andere Websites gelangen. Fehlen passende Header, greift die Standardregel des Browsers, die Same-Origin-Policy, und der Browser blockiert das Lesen. Die „CORS policy“ aus der Fehlermeldung meint genau diese Regeln.

Daraus folgen drei Dinge. Die Logs des Servers sehen normal aus, weil der Browser den Fehler erzeugt hat. Ihr Code bekommt nur einen allgemeinen Fehler, TypeError: Failed to fetch von fetch() oder AxiosError: Network Error (Code ERR_NETWORK) von Axios, und der Grund steht nur in der Konsole. Und die Lösung gehört auf den Server, der antwortet, nicht in den Code, der fragt.

Was ist ein Origin, und was blockiert die Same-Origin-Policy?#

Ein Origin (Ursprung) besteht aus Schema, Host und Port einer URL. Zwei URLs haben nur dann denselben Origin, wenn alle drei übereinstimmen:

• http://localhost:5173 und http://localhost:3001: verschiedene Ports, verschiedene Origins.
• http://example.com und https://example.com: verschiedene Schemas.
• https://example.com und https://api.example.com: verschiedene Hosts; eine Subdomain ist ein eigener Origin.
• https://example.com/shop und https://example.com/api: derselbe Origin; der Pfad zählt nicht.

Die Same-Origin-Policy erlaubt einer Seite weiterhin, Bilder, Skripte und Stylesheets von anderen Websites einzubinden, auf sie zu verlinken und Formulare an sie zu senden. Was sie unterbindet, ist das Lesen: Ein Skript kann eine Antwort von einem anderen Origin nicht lesen, solange dieser Origin es nicht erlaubt (MDN: Same-origin policy). CORS ist der Weg, auf dem der Server diese Erlaubnis erteilt.

Wie läuft eine Cross-Origin-Anfrage Schritt für Schritt ab?#

1. Ihre Seite auf Origin A ruft fetch() für eine URL auf Origin B auf.
2. Der Browser prüft, ob die Anfrage „einfach“ ist. Wenn nicht, schickt er zuerst einen Preflight (nächster Abschnitt).
3. Er fügt einen Origin-Header hinzu, etwa Origin: http://localhost:5173. Skripte können ihn weder setzen noch entfernen.
4. Der Server führt seinen Code aus und antwortet. Was der Code getan hat, ist damit bereits geschehen.
5. Der Browser vergleicht den Access-Control-Allow-Origin der Antwort mit dem Origin der Seite. Er akzeptiert eine exakte Übereinstimmung oder *, wenn keine Zugangsdaten wie Cookies mitgeschickt wurden.
6. Bei Übereinstimmung erhält Ihr Code die Antwort; andernfalls verwirft der Browser sie, das Promise wird abgelehnt, und die Konsole nennt den Grund.

Schritt 4 übersehen viele: CORS hält Anfragen nicht vom Server fern, und curl, Skripte und andere Server lassen Schritt 5 ganz aus. CORS schützt Besucher, damit eine Seite, die sie öffnen, nicht mit ihren Cookies ihre Daten auf anderen Websites lesen kann; Ihre API schützt es nicht.

Einfache Anfragen und Preflight: Warum GET funktioniert, POST aber nicht#

Eine Anfrage ist „einfach“, wenn sie GET, HEAD oder POST verwendet und nur Header von der Safelist enthält: Accept, Accept-Language, Content-Language, Range sowie Content-Type mit application/x-www-form-urlencoded, multipart/form-data oder text/plain. Alles andere bekommt einen Preflight: eine OPTIONS-Anfrage mit Access-Control-Request-Method und Access-Control-Request-Headers, nach der der Browser die eigentliche Anfrage nur sendet, wenn die Antwort sie erlaubt (MDN: CORS). Ein JSON-Body, ein Authorization-Header, PUT, PATCH, DELETE oder ein eigener Header wie X-Request-ID lösen einen Preflight aus.

Wir haben von einer Seite auf Port 5173 ein einfaches GET und ein POST mit JSON-Body an eine API auf Port 3001 geschickt, die keine CORS-Header sendet. Die API protokollierte:

[no-cors-api] GET /api/products origin=http://localhost:5173
[no-cors-api] OPTIONS /api/products origin=http://localhost:5173

Das GET wurde mit 200 und den Daten beantwortet, und der Browser blockierte es trotzdem. Vom POST kam nur der Preflight an; er scheiterte, also wurde das POST nie gesendet. Ein einfaches Cross-Origin-POST, etwa ein formularkodiertes, erreicht den Server dagegen und wird ausgeführt, obwohl die Seite einen Fehler sieht. Schützen Sie solche Aktionen deshalb mit Authentifizierung und CSRF-Tokens, nicht mit CORS.

Mit Access-Control-Max-Age darf der Browser eine Preflight-Antwort zwischenspeichern. Der Standardwert im Fetch Standard beträgt 5 Sekunden; Chromium begrenzt den Wert auf 2 Stunden, Firefox auf 24 Stunden.

Was bedeuten die einzelnen „blocked by CORS policy“-Meldungen?#

Jede Chrome-Meldung beginnt mit Access to fetch at '<URL>' from origin '<origin>' has been blocked by CORS policy:, bei Axios und XMLHttpRequest mit Access to XMLHttpRequest at. Chromium hinterlegt diese Texte fest auf Englisch im Quellcode, deshalb erscheinen sie auch in einem deutschsprachigen Browser auf Englisch. Der Text nach dem Doppelpunkt ist die Ursache. Die ersten fünf Zeilen der Tabelle sind in unserem Test mit einem Browser auf Basis von Chromium 152 wortgleich erschienen; die übrigen stammen aus dem Quellcode von Chromium.

Ältere Chrome-Versionen hängten einen Satz an, der mode: 'no-cors' vorschlug; Chromium hat ihn im März 2025 gestrichen, weil er in die Irre führte (den Grund nennen die Häufigen Fragen unten). Firefox schreibt Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at … (Reason: CORS header 'Access-Control-Allow-Origin' missing).

Wie finden Sie die eigentliche Ursache?#

Öffnen Sie die Entwicklertools (F12) und lesen Sie die Zeile im Tab Console (in der deutschen Oberfläche Konsole): URL, Origin, Grund. Im Tab Network (deutsch Netzwerk) zeigt die blockierte Anfrage in der Spalte Status den Eintrag CORS error (deutsch CORS-Fehler), und ein Aufruf mit Preflight hat einen eigenen OPTIONS-Eintrag, in dessen Spalte Initiator Preflight steht. Klicken Sie den Eintrag an, um die Header zu sehen.

Der echte Statuscode geht leicht unter. In unserem Test antwortete ein Gateway mit 502 ohne CORS-Header: Die Konsole zeigte nur die Zeile „No 'Access-Control-Allow-Origin' header“, während curl -i auf dieselbe URL HTTP/1.1 502 Bad Gateway ausgab. Fehlerseiten von nginx, Load Balancern oder einer abgestürzten App tragen selten CORS-Header, deshalb sehen Ausfälle wie CORS-Probleme aus. nginx wendet add_header nur auf Antworten mit 200, 201, 204, 206, 301, 302, 303, 304, 307 und 308 an, sofern Sie nicht den Parameter always ergänzen (nginx-Dokumentation).

Wie beheben Sie einen CORS-Fehler bei Ihrer eigenen API?#

Senden Sie die Header von der API selbst, und zwar für die exakten Origins Ihres Frontends. Wir haben jedes Snippet am 6. Oktober 2026 mit Node.js 24.11, Express 5.2.1, cors 2.8.6, Vite 8.3.3, Python 3.13, Flask 3.1.3 und Flask-CORS 6.0.5 getestet.

Express#

Installieren Sie mit npm install express cors, und setzen Sie "type": "module" in der package.json.

// server.js: eine API, die genau ein Frontend zulässt (Express 5, cors 2.8)
import express from "express";
import cors from "cors";

const app = express();

app.use(cors({
  origin: ["https://app.example.com", "http://localhost:5173"],
  methods: ["GET", "POST", "PUT", "DELETE"],
  allowedHeaders: ["Content-Type", "Authorization"],
  credentials: true,
  maxAge: 600,
}));
app.use(express.json());

app.get("/api/products", (req, res) => {
  res.json([{ id: 1, name: "Desk lamp" }]);
});

app.post("/api/products", (req, res) => {
  res.status(201).json({ created: req.body });
});

app.listen(3000, () => console.log("API on http://localhost:3000"));

Mit app.use() vor den Routen registriert, beantwortet die Middleware auch jeden OPTIONS-Preflight (cors-Middleware von Express). Schreiben Sie die Origins genau so, wie der Browser sie sendet, ohne Schrägstrich am Ende. Andere Origins erhalten keinen Access-Control-Allow-Origin-Header, und genau das ist gewollt. Behalten Sie credentials: true nur, wenn das Frontend Cookies mit credentials: "include" sendet.

Prüfen Sie den Preflight im Terminal:

curl -i -X OPTIONS http://localhost:3000/api/products \
  -H "Origin: http://localhost:5173" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: content-type"

Die relevanten Zeilen aus unserem Lauf:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://localhost:5173
Vary: Origin
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,POST,PUT,DELETE
Access-Control-Allow-Headers: Content-Type,Authorization
Access-Control-Max-Age: 600

Vary: Origin sagt Caches und CDNs, dass die Antwort vom Origin-Header abhängt. Mit Origin: https://evil.example liefert derselbe Befehl 204, aber ohne die Zeile Access-Control-Allow-Origin.

Flask#

Installieren Sie mit pip install flask flask-cors.

# app.py: dieselbe API in Flask 3 mit Flask-CORS 6
from flask import Flask, jsonify, request
from flask_cors import CORS

app = Flask(__name__)
CORS(
    app,
    resources={r"/api/*": {"origins": ["https://app.example.com", "http://localhost:5173"]}},
    allow_headers=["Content-Type", "Authorization"],
    supports_credentials=True,
    max_age=600,
)


@app.get("/api/products")
def list_products():
    return jsonify([{"id": 1, "name": "Desk lamp"}])


@app.post("/api/products")
def create_product():
    return jsonify({"created": request.get_json()}), 201


if __name__ == "__main__":
    app.run(port=5000)

In unserem Lauf lieferte der Preflight 200 mit dem Origin, den Methoden und Vary: Origin, und das POST der Seite ergab 201. Übergeben Sie bei supports_credentials=True immer eine Origin-Liste: Ohne sie hat Flask-CORS 6.0.5 uns einen beliebigen Origin, https://evil.example, zusammen mit Access-Control-Allow-Credentials: true zurückgespiegelt.

nginx, Gateways und CDNs#

Setzt ein Reverse-Proxy die Header statt der App, geben Sie jedem add_header den Parameter always, damit auch Fehlerantworten sie tragen, und lassen Sie nur eine Schicht die Header setzen. Kopieren Sie nie einen beliebigen eingehenden Origin in die Antwort, während Sie Credentials erlauben: Dann könnte jede Website mit den Cookies Ihrer Nutzer deren Daten lesen. Prüfen Sie Origins gegen eine feste Liste.

Lokale Entwicklung: Der Dev-Server leitet die API weiter#

In der Entwicklung ist die einfachste Lösung, die API auf denselben Origin zu bringen. Der Dev-Server von Vite kann jeden Pfad weiterleiten, der mit /api beginnt:

// vite.config.js: in der Entwicklung geht /api über Vite an die API
import { defineConfig } from "vite";

export default defineConfig({
  server: {
    port: 5173,
    proxy: {
      "/api": {
        target: "http://localhost:3000",
        changeOrigin: true,
      },
    },
  },
});

Das Frontend ruft fetch("/api/products") ohne Host auf. Der Browser sieht seinen eigenen Origin, also findet keine CORS-Prüfung statt, und Vite reicht die Anfrage an Port 3000 weiter; in unserem Test lieferte GET 200 und POST 201. changeOrigin setzt den Host-Header auf das Ziel. webpack-dev-server bietet dasselbe über devServer.proxy. In der Produktion stellen Sie Frontend und API über Ihren Webserver unter einem Origin bereit oder behalten die CORS-Einrichtung von oben.

Wenn die API nicht Ihnen gehört: Aufruf über Ihr Backend#

Eine Drittanbieter-API ohne CORS-Header ist meist für Server gedacht, oft weil ihr geheimer Schlüssel nie in einen Browser gelangen darf. Fügen Sie Ihrem Backend eine Route hinzu: Der Browser ruft Ihren Origin auf, Ihr Server ruft die API auf.

// relay.js: Ihr Backend ruft die Drittanbieter-API auf; der Browser spricht nur mit Ihnen
import express from "express";

const app = express();
const PARTNER_URL = "https://api.partner.example/v1/products";

app.get("/api/partner-products", async (req, res) => {
  try {
    const r = await fetch(PARTNER_URL, {
      headers: { Authorization: `Bearer ${process.env.PARTNER_API_KEY}` },
      signal: AbortSignal.timeout(10_000),
    });
    res.status(r.status).type(r.headers.get("content-type") ?? "application/json");
    res.send(await r.text());
  } catch (err) {
    res.status(502).json({ error: "partner API unreachable", detail: err.cause?.code ?? err.name });
  }
});

app.listen(8080, () => console.log("relay on http://localhost:8080"));

Gegen einen lokalen Ersatz für die Partner-API ohne CORS-Header lieferte die Route das JSON mit 200. Stellen Sie die Route vom Origin der Seite aus bereit; der Schlüssel bleibt in einer Umgebungsvariablen auf dem Server. Header, Bodys und Authentifizierung mit serverseitigem fetch und Axios behandelt der Beitrag cURL in JavaScript.

Halten Sie das Ziel fest. Eine Route, die abruft, was auch immer in ?url= ankommt, macht Ihren Server zu einem offenen Proxy, den jeder nutzen kann, auch gegen interne Adressen, die nur Ihr Server erreicht. Die Nutzungsbedingungen und Rate Limits der API gelten weiter: Der Aufruf ist umgezogen, die Regeln nicht.

Warum öffentliche CORS-Proxys ein Risiko sind#

Ein öffentlicher CORS-Proxy ruft eine URL für Sie ab und hängt Access-Control-Allow-Origin: * an die Antwort. Der Fehler verschwindet, aber:

• Der Betreiber sieht die vollständige URL, jeden Header einschließlich API-Schlüsseln und Tokens sowie die Antwort.
• Er kann die Antwort verändern, und Ihre Seite vertraut ihr.
• Die Anfragen Ihrer Nutzer laufen über ein Unternehmen, mit dem Sie keine Vereinbarung haben.
• Seine Rate Limits und Ausfälle werden zu Ihren.

CORS und Web Scraping: Warum Ihr Python- oder Node.js-Skript den Fehler nie sieht#

CORS gibt es nur in Browsern. Wir haben dieselbe API, die der Browser blockiert hatte, diesmal aus Node.js 24 abgefragt:

// Dieselbe Anfrage aus Node.js: kein Browser, keine CORS-Prüfung
const r = await fetch("http://localhost:3001/api/products");
console.log(r.status, r.headers.get("access-control-allow-origin"), await r.text());

200 null [{"id":1,"name":"Desk lamp"}]

Kein Access-Control-Allow-Origin-Header, und Node.js liest die Antwort trotzdem; Requests in Python und curl verhalten sich genauso. Wenn Sie versuchen, mit fetch() in der Browserkonsole oder in einer Frontend-App Daten zu sammeln, sagt Ihnen der CORS-Fehler, dass die Aufgabe in serverseitigen Code gehört. Welche Sprache dafür passt, vergleicht Web Scraping: JavaScript oder Python?. Auch dort gelten die Regeln der Website: Halten Sie sich an robots.txt, halten Sie die Anfragerate niedrig, und nutzen Sie die offizielle API, wenn es eine gibt.

Ein Proxy behebt keinen CORS-Fehler. Der Browser vergleicht den Origin der Seite mit dem Access-Control-Allow-Origin-Header, und die IP-Adresse ist nicht Teil dieser Prüfung; ein Residential-Proxy, ein Datacenter-Proxy oder ein VPN ändert also nichts. Proxys gehören in den HTTP-Client Ihres serverseitigen Codes, wie in Proxys in Node.js verwenden gezeigt.

Für erlaubte Datenerhebung, die lokale Ergebnisse aus vielen Ländern und Städten braucht, schickt ein Residential-Proxy die Anfragen über private Internetanschlüsse, mit Targeting nach Land und Stadt.

Für große Mengen an Anfragen an öffentliche APIs und schwach geschützte Seiten bietet ein Datacenter-Proxy dedizierte IPv4-Adressen mit Traffic ohne Kontingent.

Wer stößt auf CORS-Fehler?#

• Frontend-Entwickler, deren App und API auf verschiedenen Ports laufen.
• Single-Page-Apps, die eine Drittanbieter-API direkt aus dem Browser aufrufen.
• Teams, die eine API auf eine Subdomain wie api.example.com oder auf https umziehen.
• KI-generierte Frontends, die eine API direkt aufrufen, manchmal mit dem Schlüssel in der Seite.

Häufige Fehler#

• Access-Control-Allow-Origin in die Anfrage schreiben. Das ist ein Antwort-Header; in fetch() wird er zu einem eigenen Header, der einen Preflight auslöst.
• mode: "no-cors" verwenden. Die Antwort kommt undurchsichtig (opaque) zurück: Status 0, der Body ist nicht lesbar.
• Eine „Allow CORS“-Erweiterung oder abgeschaltete Web-Sicherheit. Das ändert nur Ihren eigenen Browser, und eine solche Erweiterung kann die Seiten lesen, auf denen sie läuft.
• Mit * antworten, während das Frontend Cookies sendet. Der Browser lehnt diese Kombination ab.
• app.options("*", cors()) in Express 5. Die App bricht beim Start mit PathError [TypeError]: Missing parameter name at index 1: * ab; app.use(cors()) beantwortet Preflights bereits.
• Authentifizierungs-Middleware, die OPTIONS ablehnt. Preflights tragen kein Token und scheitern deshalb mit „It does not have HTTP ok status“.

Entscheidungshilfe#

Häufige Fragen#

Warum funktionieren Postman und curl, während der Browser einen CORS-Fehler zeigt?#

Nur Browser setzen CORS durch. Der Server schickt jedem Client dieselbe Antwort, und nur der Browser prüft Access-Control-Allow-Origin, bevor er sie an ein Skript übergibt. Ein funktionierender curl-Aufruf beweist, dass die API läuft, nicht, dass ein Browser die Antwort lesen darf.

Warum bekomme ich auf localhost einen CORS-Fehler?#

Ein anderer Port ist ein anderer Origin: localhost:5173 und localhost:3000 sind zwei Origins auf einem Rechner. Erlauben Sie den Origin des Frontends in der API, oder nutzen Sie den Dev-Server-Proxy. Unabhängig davon braucht seit Chrome 142 eine öffentliche Website, die localhost oder ein Gerät in Ihrem Heimnetz aufruft, Ihre Erlaubnis; lehnen Sie ab, meldet die Konsole einen verweigerten Adressraum loopback oder local.

Behebt mode: "no-cors" einen CORS-Fehler?#

Nein. Die Anfrage wird gesendet, aber der Browser liefert eine undurchsichtige (opaque) Antwort; in unserem Test war der Status 0, der Typ opaque und der Body nicht lesbar. Das passt nur für Anfragen, deren Antwort Sie nie lesen.

Ist CORS eine Sicherheitsfunktion für meine API?#

Nein. CORS verhindert, dass eine Website mit den Cookies eines Besuchers die Daten einer anderen Website liest, aber jeder kann Ihre API weiterhin per Skript aufrufen. Schützen Sie die API mit Authentifizierung, Autorisierung und Rate Limits.

Kann ein Proxy oder VPN einen CORS-Fehler beheben?#

Nein. Der Browser vergleicht den Origin der Seite mit dem Access-Control-Allow-Origin-Header der Antwort; die IP-Adresse ist nicht Teil der Prüfung.

Warum schlägt nur meine POST-Anfrage fehl, während GET funktioniert?#

Das POST braucht wahrscheinlich einen Preflight, wegen eines JSON-Bodys, eines Authorization-Headers oder eines eigenen Headers. Beantwortet die API die OPTIONS-Anfrage nicht korrekt, sendet der Browser das POST nie. Suchen Sie den OPTIONS-Eintrag im Tab Network (Netzwerk), oder senden Sie den Preflight mit curl.

Fazit#

Ein CORS-Fehler bedeutet, dass der Browser die Antwort eines anderen Origins nicht an Ihr Skript übergibt; die Anfrage hat den Server meist erreicht. Lesen Sie den Grund in der Konsole, prüfen Sie den echten Status mit curl, und beheben Sie das Problem auf dem Server: exakte Origins, eine Antwort auf OPTIONS, die richtigen Methoden und Header, Vary: Origin. Nutzen Sie beim Entwickeln den Dev-Server-Proxy und für APIs, die Sie nicht kontrollieren, Ihr eigenes Backend. Datenerhebung gehört in serverseitigen Code, wo CORS nicht gilt; die Proxy-Typen für diese Arbeit finden Sie auf unserer Seite zu Proxy-Diensten.