Du rufst eine API aus deiner Web-App auf – alles sieht korrekt aus, der API-Key stimmt, die URL ist richtig – und trotzdem erscheint in der Browser-Konsole eine rote Fehlermeldung: "Access to fetch at '...' has been blocked by CORS policy". Frustrierend, aber erklärbar.
CORS ist kein Bug, kein Serverausfall und kein Fehler in deinem Code. Es ist ein Sicherheitsmechanismus des Browsers, der dich und deine Nutzer schützt. In diesem Artikel erklären wir, was CORS ist, warum es existiert, wie es technisch funktioniert – und wie du es in instantapi.io richtig konfigurierst.
Die Same-Origin Policy – das Fundament von CORS
Um CORS zu verstehen, muss man zuerst die Same-Origin Policy (SOP) kennen. Sie ist eine Sicherheitsregel, die in jedem modernen Browser eingebaut ist und besagt:
Ein Skript auf einer Webseite darf nur dann Daten von einer anderen URL laden, wenn beide URLs denselben Ursprung (Origin) haben. Der Ursprung besteht aus Protokoll, Domain und Port – alle drei müssen übereinstimmen.
Was ist ein "Ursprung" (Origin) genau? Er setzt sich aus drei Bestandteilen zusammen: Protokoll (z. B. https), Domain (z. B. meineshop.de) und Port (z. B. 443). Ändert sich auch nur einer dieser drei Werte, spricht man von einem anderen Ursprung (Cross-Origin).
| URL | Same-Origin zu https://example.com? | Grund |
|---|---|---|
| https://example.com/api/data | Ja | Identischer Ursprung |
| http://example.com/api/data | Nein | Anderes Protokoll (http vs. https) |
| https://api.example.com/data | Nein | Andere Subdomain |
| https://example.com:8080/data | Nein | Anderer Port |
| https://other.com/data | Nein | Andere Domain |
Die Same-Origin Policy verhindert, dass eine bösartige Website im Hintergrund Anfragen an deine Bank, deinen E-Mail-Dienst oder andere sensible APIs stellen kann – in deinem Namen, mit deinen Cookies. Ohne sie wäre das Web fundamental unsicher.
Was ist CORS?
CORS steht für Cross-Origin Resource Sharing und ist ein kontrollierter Mechanismus, mit dem Server explizit erlauben können, dass Browser aus anderen Ursprüngen auf ihre Ressourcen zugreifen.
Kurz gesagt: CORS ist die offizielle Ausnahme zur Same-Origin Policy. Der Server sagt dem Browser: "Ja, Anfragen von https://meine-app.de sind erlaubt." Der Browser prüft diese Aussage und lässt den Zugriff zu – oder blockiert ihn.
Die Türsteher-Analogie
Stell dir vor, du arbeitest in Gebäude A und möchtest Akten aus Gebäude B abholen. Der Türsteher in Gebäude B (= der Browser) fragt zunächst beim Empfang (= dem Server) nach, ob Mitarbeiter aus Gebäude A Zutritt haben. Wenn der Empfang eine schriftliche Genehmigung ausstellt (= der CORS-Header), lässt der Türsteher dich durch. Gibt es keine Genehmigung, wirst du abgewiesen – egal wie berechtigt dein Anliegen ist.
So sieht ein CORS-Fehler aus
Wenn dein Browser eine Cross-Origin-Anfrage blockiert, siehst du in der Entwicklerkonsole (F12 → Console) eine Meldung wie diese:
Wichtig zu verstehen: Die Anfrage hat den Server oft bereits erreicht. Der Server hat sogar geantwortet. Aber der Browser verwirft die Antwort, weil die erforderlichen CORS-Header fehlen. Der Fehler liegt also nicht in der Netzwerkverbindung, sondern im fehlenden Einverständnis des Servers.
CORS gilt ausschließlich im Browser. Anfragen von deinem Server, von curl, von Postman oder von automatisierten Tools wie Make oder Zapier werden von CORS nicht betroffen. Dort greift die Same-Origin Policy nicht.
Wie CORS-Header funktionieren
Der zentrale CORS-Header ist Access-Control-Allow-Origin. Er teilt dem Browser mit, welche Ursprünge Zugriff erhalten. Der Server schickt ihn in der HTTP-Antwort zurück:
Der Browser liest diese Header und entscheidet: Stimmt der Ursprung der Anfrage mit dem erlaubten Ursprung überein? Wenn ja, wird die Antwort an dein JavaScript übergeben. Wenn nein, wird sie verworfen – mit dem bekannten Fehler in der Konsole.
Wildcard vs. spezifische Ursprünge
Du kannst entweder einen konkreten Ursprung angeben oder einen Wildcard (*) verwenden, der alle Ursprünge erlaubt:
| Header-Wert | Bedeutung | Wann geeignet |
|---|---|---|
* | Alle Ursprünge erlaubt | Öffentliche, read-only APIs ohne Authentifizierung |
https://meine-app.de | Nur dieser Ursprung erlaubt | Produktions-APIs mit sensiblen Daten |
https://dev.meine-app.de | Nur diese Subdomain erlaubt | Staging-Umgebungen |
Verwende den Wildcard * nie in Kombination mit Authentifizierung (z. B. Cookies oder Authorization-Header). Browser verweigern das und du musst explizite Ursprünge angeben. Für APIs mit API-Keys ist der Wildcard akzeptabel, wenn die Daten nicht besonders sensibel sind.
Preflight-Anfragen (OPTIONS)
Bei bestimmten Anfragen – insbesondere bei POST/PUT/DELETE-Anfragen oder wenn benutzerdefinierte Header wie x-api-key gesendet werden – schickt der Browser zunächst eine sogenannte Preflight-Anfrage mit der HTTP-Methode OPTIONS.
Diese Preflight-Anfrage fragt beim Server nach: "Darf ich überhaupt diese Art von Anfrage stellen?" Erst wenn der Server mit den passenden CORS-Headern antwortet, sendet der Browser die eigentliche Anfrage.
Der Header Access-Control-Max-Age gibt an, wie lange (in Sekunden) der Browser das Preflight-Ergebnis zwischenspeichern darf – bei 86400 ist das ein ganzer Tag. Das reduziert unnötige Preflight-Anfragen erheblich.
Häufige CORS-Fehler und ihre Ursachen
Fehler 1: Fehlender Header
Der Server gibt den Header Access-Control-Allow-Origin schlicht nicht zurück. Ursache: CORS ist auf dem Server nicht konfiguriert oder die Middleware ist nicht aktiv.
Fehler 2: Falscher Ursprung
Der Header gibt https://meine-app.de an, aber die App läuft lokal auf http://localhost:3000. Selbst ein fehlendes www oder ein abweichendes Protokoll (http vs. https) führt zum Fehler.
Fehler 3: OPTIONS-Anfragen werden nicht beantwortet
Der Server versteht die Preflight-Anfrage nicht und antwortet mit 404 oder 405 Method Not Allowed. Lösung: Den Server so konfigurieren, dass OPTIONS-Anfragen immer korrekt mit CORS-Headern beantwortet werden.
Fehler 4: Header nicht in Allow-Headers
Du sendest einen Header wie x-api-key, aber dieser ist nicht im Access-Control-Allow-Headers-Response aufgelistet. Jeder nicht-standardmäßige Header muss dort explizit erlaubt werden.
CORS in instantapi.io konfigurieren
instantapi.io bietet eine komfortable CORS-Whitelist in den Einstellungen jedes Datasets. Dort kannst du festlegen, welche Ursprünge direkt aus dem Browser auf deine API zugreifen dürfen.
So richtest du es ein:
- Öffne dein Dataset im instantapi.io Dashboard.
- Navigiere zu Einstellungen → CORS / Erlaubte Ursprünge.
- Trage deine Domain ein, z. B.
https://meine-app.de. Mehrere Ursprünge werden zeilenweise eingetragen. - Für lokale Entwicklung: Trage
http://localhost:3000(oder deinen lokalen Port) zusätzlich ein. - Speichere die Einstellungen – die CORS-Header werden ab sofort automatisch gesetzt.
Füge während der Entwicklung http://localhost:3000 (oder welchen Port deine lokale App verwendet) zur CORS-Whitelist hinzu. Entferne diesen Eintrag, bevor du die API in Produktion gibst – oder behalte ihn, wenn du parallel weiterentwickelst.
Wann CORS keine Rolle spielt
CORS ist ein reiner Browser-Mechanismus. Es gibt eine wichtige Situation, in der du dir darüber keine Gedanken machen musst: bei Server-zu-Server-Kommunikation.
Wenn dein Node.js-, Python- oder PHP-Backend eine Anfrage an die instantapi.io API stellt, gibt es keine Same-Origin Policy – Server kennen diesen Mechanismus nicht. Das bedeutet:
- Anfragen von Zapier, Make, n8n oder anderen Automatisierungstools: kein CORS-Problem.
- API-Aufrufe aus deinem Backend-Code: kein CORS-Problem.
- Postman, Insomnia, curl: kein CORS-Problem.
- JavaScript im Browser, das direkt die API aufruft: CORS-Regeln gelten.
Wenn deine App also ausschließlich server-seitig auf die API zugreift und das Ergebnis dann an den Browser ausliefert, brauchst du CORS überhaupt nicht zu konfigurieren.
Fazit: CORS verstehen statt bekämpfen
CORS ist kein Feind – es ist eine wichtige Sicherheitsebene, die Nutzer vor bösartigen Cross-Origin-Anfragen schützt. Sobald du das Prinzip verstehst, sind CORS-Fehler kein Rätsel mehr, sondern lösbare Konfigurationsfragen.
Die goldene Regel: Sei so restriktiv wie möglich. Trage nur die Ursprünge in deine CORS-Whitelist ein, die wirklich Zugriff benötigen. instantapi.io macht dir das einfach – du konfigurierst erlaubte Ursprünge direkt im Dashboard, ohne Servercode anfassen zu müssen.
CORS-Konfiguration in Sekunden
Trage deine erlaubten Ursprünge direkt im instantapi.io Dashboard ein – keine Serverkonfiguration, kein Code. Einfach starten.
Jetzt kostenlos ausprobieren →