So beheben Sie den CORS-Fehler „No Access-Control-Allow-Origin“-Header im Jahr 2026

Sie stellen eine Anfrage von Ihrem Frontend an eine API und der Browser blockiert sie mit:Access to fetch at '...' from origin '...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Dies ist einer der häufigsten und missverstandenen Fehler in der Webentwicklung. Hier erfahren Sie, was es tatsächlich verursacht und wie Sie es richtig beheben können.

Was CORS eigentlich ist

CORS (Cross-Origin Resource Sharing) ist ein Browser-Sicherheitsmechanismus. Wenn Ihr JavaScript aufhttps://app.example.com stellt eine Anfrage anhttps://api.other.com, betrachtet der Browser es als eine Cross-Origin-Anfrage und verlangt, dass der Server dies explizit über Antwortheader zulässt. Wenn der Server keinAccess-Control-Allow-Originsendet Wenn Sie einen Header eingeben, der Ihren Ursprung enthält, blockiert der Browser die Antwort – selbst wenn der Server die Anfrage erfolgreich verarbeitet hat.

Wichtige Erkenntnis:CORS wird vom Browser erzwungen und der Fix befindet sich auf dem Server, nicht in Ihrem Frontend-Code. Sie können einen CORS-Fehler nicht beheben, indem Sie nur Ihren Abrufaufruf ändern.

Fix 1: Konfigurieren Sie den Server zum Senden des Headers

Die richtige Lösung besteht darin, die API mit den richtigen CORS-Headern antworten zu lassen. Verwenden Sie in Express dascors Middleware:

const cors = require('cors');

app.use(cors({
  origin: 'https://app.example.com',
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true
}));

Setzeorigin zum genauen Ursprung Ihres Frontends. Verwenden Sie keinen Platzhalter* in der Produktion, wenn Sie Anmeldeinformationen (Cookies oder Authentifizierungsheader) senden – Browser lehnen die Kombination vonAccess-Control-Allow-Origin: *ab mitcredentials: true.

Fix 2: Preflight-Anfragen (OPTIONS) verarbeiten

Für jede Anfrage, die kein einfaches GET/POST ist – zum Beispiel eine, dieContent-Type: application/jsonsendet oder einAuthorization Header – der Browser sendet zunächst einen PreflightOPTIONS um Erlaubnis bitten. Ihr Server muss darauf mit den entsprechenden Headern antworten. Dascors Die obige Middleware erledigt dies automatisch, aber wenn Sie Header manuell festlegen, müssen Sie OPTIONS explizit behandeln:

app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'https://app.example.com');
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204); // Respond to preflight, do not fall through
  }
  next();
});

Ein häufiger Fehler besteht darin, nicht auf den OPTIONS-Preflight zu reagieren – der Browser sendet ihn, erhält keine gültige CORS-Antwort und blockiert die eigentliche Anfrage, bevor sie jemals gestellt wird.

Fix 3: Passen Sie den Ursprung genau an

Der Ursprung muss genau übereinstimmen – Protokoll, Domäne und Port zählen alle. Dies sind alles unterschiedliche Ursprünge des Browsers:

Wenn Ihr zulässiger Ursprunghttps://example.comist aber Ihre App wird vonhttps://www.example.comgeladen , CORS blockiert es. Lassen Sie jeden Ursprung zu, den die App tatsächlich verwendet, oder normalisieren Sie ihn auf einen.

Fix 4: Verwenden Sie einen dynamischen Ursprung für mehrere Frontends

Wenn mehrere Ursprünge Zugriff benötigen (Staging, Produktion, lokaler Host), validieren Sie anhand einer Zulassungsliste, anstatt eine fest zu codieren:

const allowed = [
  'https://app.example.com',
  'https://staging.example.com',
  'http://localhost:3000'
];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowed.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true
}));

Fix 5: Für lokale Entwicklung verwenden Sie einen Proxy

Während der Entwicklung können Sie CORS umgehen, indem Sie API-Anfragen über Ihren Entwicklungsserver weiterleiten, sodass sie scheinbar denselben Ursprung haben. In Vite:

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:5000',
        changeOrigin: true
      }
    }
  }
};

Jetzt ruft Ihr Frontend/api/...auf auf seinem eigenen Ursprung und der Entwicklungsserver leitet es weiter. Dies ist eine praktische Entwicklungsmaßnahme und kein Produktions-Fix – die Produktion benötigt immer noch die richtigen CORS-Header auf der API.

Was man NICHT tun sollte

Greifen Sie nicht nach Browsererweiterungen, die CORS deaktivieren, und schlagen Sie nicht aufAccess-Control-Allow-Origin: * auf alles, damit der Fehler verschwindet. Der Platzhalter macht Ihre API für jede Website im Internet verfügbar und unterbindet Anfragen mit Anmeldeinformationen. CORS ist eine Sicherheitsfunktion – konfigurieren Sie sie richtig, anstatt sie zu deaktivieren.

Häufig gestellte Fragen

F: Warum funktioniert die Anfrage in Postman, aber nicht im Browser?
A: Postman erzwingt CORS nicht – nur Browser tun dies. Die den Server erreichende Anfrage beweist, dass der Server funktioniert. Der Browser blockiert die Antwort, da die CORS-Header fehlen. Korrigieren Sie die Header auf dem Server.

F: Kann ich CORS vom Frontend aus reparieren?
A: Nein. CORS-Header müssen von dem Server stammen, der auf die Anfrage antwortet. Die einzige Problemumgehung auf der Frontend-Seite ist ein Dev-Proxy, der Anfragen während der Entwicklung vom gleichen Ursprung herstellt.

F: Warum schlägt meine Preflight-OPTIONS-Anfrage fehl?
A: Der Server antwortet auf OPTIONS nicht mit den richtigen CORS-Headern und einem 2xx-Status. Stellen Sie sicher, dass Ihre CORS-Middleware vor Ihren Routen ausgeführt wird, oder behandeln Sie OPTIONS explizit und geben Sie 204 zurück.

F: Warum bricht credentials: true mit origin „*“ ab?
A: Browser verbieten das Senden von Anmeldeinformationen (Cookies, Authentifizierung), wenn der zulässige Ursprung der Platzhalter*ist . Geben Sie stattdessen den genauen Ursprung an, wenn Sie Anmeldeinformationen benötigen.

F: Der Header ist vorhanden, aber er schlägt immer noch fehl. Warum?
A: Überprüfen Sie, ob der Ursprung genau übereinstimmt (Protokoll, Domäne, Port), dass der OPTIONS-Preflight verarbeitet wird und dass ein Proxy oder CDN davor den Header nicht entfernt. Überprüfen Sie die tatsächlichen Antwortheader auf der Registerkarte „Netzwerk“.

Fazit

Der Fehler „Es ist kein Access-Control-Allow-Origin-Header vorhanden“ bedeutet, dass der Browser eine Cross-Origin-Antwort blockiert hat, weilDer Server hat Ihren Ursprung nicht zugelassen. Der Fix befindet sich immer auf dem Server:Senden Sie das richtigeAccess-Control-Allow-Origin Header, verarbeiten Sie den OPTIONS-Preflight, passen Sie den Ursprung genau an und verwenden Sie niemals einen Platzhalter mit Anmeldeinformationen. Bei der lokalen Entwicklung vermeidet ein Dev-Proxy das Problem sauber. Sobald der Server die richtigen Header für Ihren genauen Ursprung zurückgibt und auf Preflight-Anfragen antwortet, verschwindet der Fehler und Ihre Anfragen werden weitergeleitet.