So beheben Sie den CORS-Fehler „Access-Control-Allow-Origin fehlender Header“.

Der FehlerAuf der angeforderten Ressourceist kein Header „Access-Control-Allow-Origin“ vorhanden ist der häufigste CORS-Fehler. Das bedeutet, dass der Browser Ihre Cross-Origin-Anfrage blockiert hat, weil der Server nicht angegeben hat, dass sie zulässig ist. Hier erfahren Sie, wie Sie das Problem richtig beheben.

Warum das passiert

Browser erzwingen aus Sicherheitsgründen die Same-Origin-Richtlinie – eine Seite unterapp.example.com kann keine Anfragen anapi.other.comstellen . Für Cross-Origin-Anfragen muss der Server einAccess-Control-Allow-Originenthalten Header, der angibt, welche Ursprünge zulässig sind. Wenn es fehlt, blockiert der Browser die Antwort und zeigt diesen Fehler an.

Kernpunkt: Dies wird vom Browser erzwungen und auf dem SERVER festgelegt. Der Client kann diesen Header nicht hinzufügen – der Server muss ihn senden.

Fix 1: Express mit dem cors-Paket

npm install cors

const cors = require('cors');

// Allow all origins (development only)
app.use(cors());

// ✅ Production: allow specific origin
app.use(cors({
  origin: 'https://app.example.com',
}));

// ✅ Multiple allowed origins
const allowed = ['https://app.example.com', 'https://admin.example.com'];
app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowed.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
}));

Fix 2: Manuelle Express-Header

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');

  // Handle preflight OPTIONS requests
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204);
  }
  next();
});

Fix 3: Nginx

location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;

    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
        add_header 'Access-Control-Max-Age' 86400;
        return 204;
    }

    proxy_pass http://localhost:3000;
}

Fix 4: Mit Anmeldeinformationen (Cookies/Auth)

// When sending cookies or auth headers cross-origin:

// Server: exact origin (NOT wildcard) + allow credentials
app.use(cors({
  origin: 'https://app.example.com',   // must be exact, not '*'
  credentials: true,
}));

// Client: include credentials
fetch('https://api.example.com/data', {
  credentials: 'include',
});

// ❌ This combination FAILS:
// origin: '*' with credentials: true
// The browser rejects wildcard origin when credentials are included

Die Entwicklungs-Proxy-Alternative

// Avoid CORS during development entirely with a dev proxy

// vite.config.ts
export default {
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:3000',
        changeOrigin: true,
      }
    }
  }
};
// Frontend calls /api/... which the dev server proxies to your backend -
// same origin, no CORS. (Production still needs proper CORS headers.)

Häufige Fehler

// 🐛 Setting CORS headers in BOTH nginx and Express
// Results in duplicate Access-Control-Allow-Origin headers,
// which the browser rejects. Set them in ONE place.

// 🐛 Wildcard with credentials
res.header('Access-Control-Allow-Origin', '*');   // fails with credentials

// 🐛 Forgetting to handle OPTIONS preflight
// PUT/DELETE/JSON requests send a preflight OPTIONS first -
// it must get a valid CORS response too

// 🐛 Trying to fix it in the frontend
// You CANNOT add Access-Control-Allow-Origin from client code -
// it must come from the server

Debuggen

# Check what headers the server actually returns
curl -I -H "Origin: https://app.example.com" https://api.example.com/data

# Look for:
# Access-Control-Allow-Origin: https://app.example.com  ← should be present

# If it's missing, the server isn't configured correctly.
# If it's the wrong origin, fix the server's allowed origins.

Häufig gestellte Fragen

F: Warum kann ich das nicht in meinem Frontend-Code beheben?
A: CORS wird vom Browser erzwungen und vom SERVER gesteuert. DasAccess-Control-Allow-Origin Der Header muss vom Server stammen, der auf die Anfrage antwortet. Kein noch so großer Frontend-Code kann es hinzufügen – Sie müssen den Server konfigurieren (oder einen Proxy verwenden).

F: Warum funktioniert es in Postman, aber nicht im Browser?
A: CORS wird nur von Browsern erzwungen. Postman und Curl stellen Anfragen direkt ohne die CORS-Prüfung des Browsers. Dies bestätigt, dass Ihr Server funktioniert – Sie müssen lediglich die CORS-Header für Browser-Clients hinzufügen.

F: Sollte ich einfach Access-Control-Allow-Origin: * verwenden?
A: Nur für wirklich öffentliche APIs ohne Anmeldeinformationen. Für alles mit Authentifizierung oder Cookies müssen Sie genaue Ursprünge angeben (Platzhalter schlagen bei Anmeldeinformationen fehl). Die Angabe genauer Ursprünge ist auch sicherer – verwenden Sie nicht* in Produktion für authentifizierte APIs.

F: Wo soll ich CORS-Header setzen – Nginx oder die App?
A: Nur ein Ort. Wenn Sie sie sowohl in Nginx als auch in Ihrer App festlegen, erhalten Sie doppelte Header, die von Browsern abgelehnt werden. Wählen Sie eine Ebene aus (normalerweise die App aus Flexibilitätsgründen oder Nginx, wenn Sie einen Reverse-Proxy haben) und konfigurieren Sie dort CORS.

F: Warum funktioniert mein POST, aber PUT schlägt fehl?
A: PUT/DELETE und Anfragen mit JSON-Texten oder benutzerdefinierten Headern lösen eine Preflight-OPTIONS-Anfrage aus. Ihr Server muss auch auf OPTIONS mit gültigen CORS-Headern antworten. Stellen Sie sicher, dass Ihre CORS-Konfiguration die OPTIONS-Methode verarbeitet, nicht nur GET/POST.

Fazit

„Es ist kein ‚Access-Control-Allow-Origin‘-Header vorhanden“ bedeutet, dass der Server dem Browser nicht mitgeteilt hat, dass Ihre Cross-Origin-Anfrage zulässig ist. Der Fix liegt immer auf dem SERVER:füge dasAccess-Control-Allow-Originhinzu Header über das CORS-Paket (Express), manuelle Header oder Nginx-Konfiguration, unter Angabe der genauen Herkunft (erforderlich bei Verwendung von Anmeldeinformationen). Behandeln Sie OPTIONS-Preflight-Anfragen, legen Sie CORS nur auf einer Ebene fest, um Duplikate zu vermeiden, und denken Sie daran, dass Sie das Problem nicht über den Frontend-Code beheben können. Für die Entwicklung vermeidet ein Entwicklungsserver-Proxy CORS vollständig – die Produktion benötigt jedoch immer ordnungsgemäße serverseitige CORS-Header.