CORS-Fehler bei Zugriff auf Dateien von anderen Servern

Info zu dieser Seite...

Kaffee-Spende

Unterstützen Sie mich mit einer Spende für diese Seite:

Du kannst die Seite teilen, bearbeiten und darauf aufbauen, solange du den Urheber angemessen nennst.
Diese Seite wurde am 30. März 2025 erstellt und ist lizenziert unter der Creative Commons Attribution 4.0 International (CC BY 4.0)

Zuletzt bearbeitet am:

Beende diesen Dialog ...

Wenn Sie mit einer externen Webanwendung oder Website auf Dateien (z.B. .json, .xml, Schriftarten) Ihres Servers zugreifen möchten, kann es zu folgender oder ähnlichen Fehlermeldungen in der Browser-Konsole kommen:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://beispiel.de/datei.json. (Reason: CORS header 'Access-Control-Allow-Origin' missing)

Access to fetch at 'https://beispiel.de/api/data' from origin 'https://fremde-app.de' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Warum tritt dieser Fehler auf? (Same-Origin Policy & CORS)

• Same-Origin Policy (SOP): Webbrowser implementieren diese grundlegende Sicherheitsrichtlinie. Sie besagt, dass ein Skript, das von einer bestimmten "Origin" (Herkunft) geladen wurde, nur auf Ressourcen derselben Origin zugreifen darf. Eine Origin ist definiert durch das Schema (z.B. http, https), den Hostnamen (z.B. meine-seite.de) und den Port (z.B. 80, 443).
  Die SOP schützt Ihre Daten davor, dass bösartige Websites im Hintergrund auf andere geöffnete Websites zugreifen (z.B. Ihre Online-Banking-Session).
• Cross-Origin Resource Sharing (CORS): Dies ist ein Mechanismus, der es Servern erlaubt, die SOP für bestimmte Anfragen zu lockern. Es ermöglicht kontrollierte Zugriffe von anderen Origins.
• Versucht eine fremde App (z.B. https://fremde-app.de) auf eine Ressource Ihres Servers (z.B. https://beispiel.de/datei.json) zuzugreifen, blockiert der Browser dies standardmäßig. Der Zugriff wird nur erlaubt, wenn Ihr Server die Anfrage mit spezifischen CORS-HTTP-Headern beantwortet, insbesondere dem Access-Control-Allow-Origin-Header.
  Mehr dazu: MDN: Cross-Origin Resource Sharing (CORS)

Preflight-Requests (OPTIONS-Anfragen)

Für bestimmte Arten von Anfragen, die als "nicht einfach" (non-simple requests) gelten – z.B. solche mit anderen Methoden als GET, HEAD, POST (mit bestimmten Content-Types) oder mit benutzerdefinierten Headern – sendet der Browser vor der eigentlichen Anfrage eine sogenannte Preflight-Anfrage mit der HTTP-Methode OPTIONS an den Server.

• Der Server muss auf diese OPTIONS-Anfrage korrekt antworten und signalisieren, ob die eigentliche Anfrage erlaubt ist (z.B. durch Setzen von Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers).
• Erst wenn die Preflight-Anfrage erfolgreich war, sendet der Browser die eigentliche Anfrage (z.B. PUT oder POST mit application/json).

Wie kann man das Problem lösen? (Server-Konfiguration)

Die Lösung besteht fast immer darin, die Konfiguration Ihres Webservers anzupassen, damit dieser die notwendigen CORS-Header sendet.

1. Server-Einstellungen anpassen

Beispiel für Apache (.htaccess)

Platzieren Sie eine .htaccess-Datei in dem Verzeichnis auf Ihrem Server, dessen Inhalte freigegeben werden sollen.

Global für alle Dateien im Ordner (und Unterordnern), in dem die .htaccess liegt:

  Header set Access-Control-Allow-Origin "*"
  # Optional: Erlaubte Methoden (wichtig für Preflight)
  # Header set Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE"
  # Optional: Erlaubte Header (wichtig für Preflight, wenn Client benutzerdefinierte Header sendet)
  # Header set Access-Control-Allow-Headers "Content-Type, Authorization"

    

Nur für bestimmte Dateitypen (z.B. .json und .xml) in einem Ordner (z.B. /public-data):

Erstellen Sie dazu die Datei /public-data/.htaccess mit folgendem Inhalt:

  
    Header set Access-Control-Allow-Origin "https://fremde-app.de"
    # Wenn die fremde App von mehreren Domains zugreifen darf:
    # Header set Access-Control-Allow-Origin "https://app1.fremde.de" env= बुरीOrigin_app1
    # Header set Access-Control-Allow-Origin "https://app2.fremde.de" env= बुरीOrigin_app2
    # SetEnvIf Origin "^https://app1\.fremde\.de$" Origin_app1
    # SetEnvIf Origin "^https://app2\.fremde\.de$" Origin_app2

    # Wichtig für Preflight-Requests und wenn Cookies gesendet werden sollen
    Header set Access-Control-Allow-Credentials "true"
    Header set Access-Control-Allow-Methods "GET, OPTIONS"
    Header set Access-Control-Allow-Headers "Content-Type" # Erlaubt z.B. 'Content-Type' im Request
  

    

Beispiel für Nginx

Fügen Sie entsprechende add_header-Direktiven in Ihrer Nginx-Serverkonfiguration (z.B. in einem server- oder location-Block) hinzu.

Für einen bestimmten Ordner (z.B. /public-api/data/):

location /public-api/data/ {
    # Erlaube Zugriff von einer spezifischen Domain
    add_header 'Access-Control-Allow-Origin' 'https://fremde-app.de';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range'; # Welche Header der Client lesen darf

    # Behandlung von Preflight-Requests
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://fremde-app.de'; # Oder '*' wenn passend
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization, X-Requested-With';
        add_header 'Access-Control-Max-Age' 1728000; # Wie lange das Ergebnis des Preflights gecacht werden darf (in Sekunden)
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        add_header 'Content-Length' 0;
        return 204; # No Content
    }

    # Normale Anfragen
    # ... Ihre normale Location-Konfiguration (z.B. try_files, root)
}
    

Beispiel für Node.js (Express)

Verwenden Sie eine Middleware, um die Header zu setzen. Das Paket cors ist hierfür sehr empfehlenswert.

Zuerst installieren: npm install cors oder yarn add cors.

Globale Freigabe für alle Routen (mit dem cors-Paket):

const express = require('express');
const cors = require('cors'); // Importieren
const app = express();

// Einfache Nutzung: Erlaubt alle Origins
// app.use(cors());

// Konfigurierte Nutzung: Nur spezifische Origin erlauben
const corsOptions = {
  origin: 'https://fremde-app.de', // Erlaubte Origin
  optionsSuccessStatus: 200 // Für ältere Browser (IE11, diverse SmartTVs)
};
app.use(cors(corsOptions));

app.get('/api/data', (req, res) => {
  res.json({ message: 'Daten von meinem Server!' });
});

app.listen(3000, () => console.log('Server läuft auf Port 3000'));
    

Freigabe nur für bestimmte Routen (z.B. alles unter /public-data/):

const express = require('express');
const cors = require('cors');
const app = express();

const publicDataCorsOptions = {
  origin: 'https://fremde-app.de',
  methods: ['GET', 'OPTIONS'] // Nur GET und OPTIONS für diesen Pfad erlauben
};

// CORS nur für Routen unter /public-data/ anwenden
app.use('/public-data', cors(publicDataCorsOptions));

app.get('/public-data/info.json', (req, res) => {
  res.json({ info: "Dies sind öffentliche Daten" });
});

app.get('/private-data/secret.json', (req, res) => {
  // Für diese Route greift die obige CORS-Konfiguration nicht
  res.json({ secret: "Dies sind private Daten" });
});

app.listen(3000, () => console.log('Server läuft auf Port 3000'));
    

Beispiel für PHP (nativ, ohne Framework)

Sie können die Header direkt am Anfang Ihres PHP-Skripts setzen, bevor irgendeine Ausgabe erfolgt.

Beispiel für eine Datei public-data/get-data.php:

 'Daten von meinem PHP-Skript!']);
?>
    

2. Nur für bestimmte Ordner/Ressourcen freigeben

Wie in den Beispielen oben gezeigt, ist es empfehlenswert, CORS-Header nicht global für den gesamten Server zu setzen, sondern gezielt:

• Bei Apache: Platzieren Sie die .htaccess nur in dem Ordner, dessen Dateien von außen erreichbar sein sollen, oder verwenden Sie , um es auf bestimmte Dateitypen einzuschränken.
• Bei Nginx: Verwenden Sie spezifische location-Blöcke.
• Bei Node.js/Express: Wenden Sie die CORS-Middleware nur auf bestimmte Routen an.
• Bei PHP: Fügen Sie die Header nur in den Skripten hinzu, die extern erreichbar sein sollen.

3. Nach der Änderung testen

Rufen Sie die Datei oder den API-Endpunkt erneut von der externen Anwendung auf. Überprüfen Sie die Browser-Konsole (meist F12-Taste) auf Fehler. Im "Netzwerk" oder "Network"-Tab der Entwicklertools können Sie die HTTP-Header der Serverantwort inspizieren und sicherstellen, dass die Access-Control-Allow-Origin und andere CORS-Header korrekt gesetzt sind.

Debugging von CORS-Fehlern

Weitere wichtige Hinweise

• Anmeldeinformationen (Credentials): Wenn Ihre Anfrage Anmeldeinformationen wie Cookies oder HTTP-Authentifizierung beinhaltet (z.B. bei fetch(url, {credentials: 'include'})), darf der Server nicht Access-Control-Allow-Origin: * senden. Stattdessen muss er die exakte Origin der anfragenden Seite zurückgeben (z.B. Access-Control-Allow-Origin: https://fremde-app.de) und zusätzlich den Header Access-Control-Allow-Credentials: true setzen.
  Siehe: MDN: Access-Control-Allow-Credentials
• Mehrere erlaubte Origins: Der Header Access-Control-Allow-Origin kann immer nur eine einzige Domain oder * enthalten. Wenn Sie mehrere spezifische Domains erlauben möchten, muss Ihre Serverlogik den Origin-Header der Anfrage prüfen und, falls dieser zu den erlaubten Domains gehört, ihn dynamisch in der Access-Control-Allow-Origin-Antwort widerspiegeln. Das cors-Paket für Node.js kann dies z.B. über eine Array-Konfiguration für origin handhaben.
• Kein Serverzugriff (Workaround CORS-Proxy): Wenn Sie absolut keinen Zugriff auf die Serverkonfiguration haben, um CORS-Header zu setzen (z.B. bei einer fremden API, die kein CORS unterstützt), können Sie als Notlösung einen sogenannten CORS-Proxy verwenden. Dieser Proxy nimmt Ihre Anfrage entgegen, leitet sie an den Zielserver weiter, fügt die notwendigen CORS-Header zur Antwort hinzu und sendet sie an Ihren Client zurück. Dies ist oft nur für Entwicklungs- oder Testzwecke geeignet oder wenn der Proxy von Ihnen selbst betrieben und vertraut wird.
  Beispiel-Proxies (mit Vorsicht verwenden!): https://cors-anywhere.herokuapp.com/ (oft überlastet), oder selbst einen aufsetzen.
  Mehr dazu: Codedamn: CORS error handling

Fazit

CORS-Fehler entstehen durch die Same-Origin Policy, eine wichtige Sicherheitsfunktion von Browsern. Die Lösung liegt in der korrekten Konfiguration des Servers, der die angefragten Ressourcen bereitstellt. Durch das Setzen der richtigen HTTP-CORS-Header kann der Server dem Browser signalisieren, dass Zugriffe von bestimmten anderen Origins erlaubt sind. Eine sorgfältige Konfiguration ist dabei sowohl für die Funktionalität als auch für die Sicherheit entscheidend. Und denken Sie daran: Der erste Blick bei Problemen gehört immer in die Browser-Konsole!