Webentwicklung

CORS

CORS (Cross-Origin Resource Sharing) ist ein Browser-Sicherheitsmechanismus, der kontrolliert, welche Webseiten API-Anfragen an welche Server stellen dürfen. Ohne CORS würde die Same-Origin-Policy des Browsers jeden Cross-Origin-Request blockieren, bei dem Protokoll, Domain oder Port abweichen; CORS ist das server-gesteuerte Verfahren, diese Sperre selektiv aufzuheben. CORS greift ausschließlich browserseitig: Server-zu-Server-Kommunikation wie PHP-cURL-Aufrufe unterliegt ihm nicht. Der Browser unterscheidet Simple Requests, die direkt…

Aktualisiert:

Was ist CORS?

CORS (Cross-Origin Resource Sharing) ist ein Browser-Sicherheitsmechanismus, der kontrolliert, welche Webseiten API-Anfragen an welche Server stellen dürfen. Ohne CORS würde die Same-Origin-Policy des Browsers jeden Cross-Origin-Request blockieren — also jeden Fetch- oder XHR-Aufruf, bei dem Protokoll, Domain oder Port von der aktuellen Seite abweichen. CORS ist das offizielle, server-gesteuerte Verfahren, diese Sperre selektiv aufzuheben.

Wichtig: CORS ist eine Browser-Sicherheit. Server-zu-Server-Kommunikation (z.B. PHP-seitige cURL-Aufrufe, WP-Cron, REST-API-Calls vom Backend) unterliegt CORS nicht. CORS greift ausschließlich, wenn JavaScript im Browser eine Anfrage an eine fremde Domain stellt.

Wie funktioniert CORS?

Der Browser unterscheidet zwischen Simple Requests und Preflighted Requests:

Simple Requests (GET/POST mit bestimmten Content-Types) werden direkt gesendet. Der Browser prüft danach, ob der Access-Control-Allow-Origin-Header in der Antwort die anfragende Origin enthält. Fehlt der Header oder stimmt die Origin nicht überein, blockiert der Browser die Antwort — der Request wurde trotzdem ausgeführt.

Preflighted Requests (DELETE, PUT, PATCH, POST mit JSON-Body, Custom Headers) lösen vorab einen OPTIONS-Request aus:

// Preflight:
OPTIONS /wp-json/wp/v2/posts HTTP/1.1
Origin: https://frontend.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, X-WP-Nonce

// Server-Antwort:
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://frontend.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-WP-Nonce
Access-Control-Max-Age: 3600

Nur wenn der Preflight erfolgreich ist, sendet der Browser den eigentlichen Request.

CORS in der Praxis

Für ein Headless-WordPress-Setup (Nuxt/Next.js Frontend, WordPress als Backend) müssen CORS-Header in WordPress konfiguriert werden:

// In functions.php oder einem Plugin:
add_action('init', function() {
    $allowed_origins = ['https://frontend.example.com', 'https://staging.example.com'];
    $origin = $_SERVER['HTTP_ORIGIN'] ?? '';

    if (in_array($origin, $allowed_origins)) {
        header("Access-Control-Allow-Origin: {$origin}");
        header('Access-Control-Allow-Credentials: true');
        header('Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE');
        header('Access-Control-Allow-Headers: Content-Type, X-WP-Nonce, Authorization');
    }

    if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
        status_header(204);
        exit();
    }
});

Access-Control-Allow-Origin: * ist verlockend einfach, aber problematisch: Mit Wildcard können keine Credentials (Cookies, Auth-Header) gesendet werden, und die Ressource ist für alle Domains zugänglich.

Was passiert bei falsch konfiguriertem CORS?

CORS-Fehler sind einer der häufigsten Frustrationspunkte in der Frontend-Entwicklung. Der Browser loggt etwas wie: CORS policy: No 'Access-Control-Allow-Origin' header is present. Der Request wurde möglicherweise ausgeführt — aber die Antwort ist für JavaScript nicht zugänglich.

Ein typischer Fehler bei WordPress: Security-Plugins oder Webserver-Konfigurationen blockieren OPTIONS-Requests mit HTTP 403 — was Preflight-Requests zum Scheitern bringt und alle POST/PUT/DELETE-Calls aus dem Frontend unterbricht.

Häufige Fragen

Kann man CORS auf Server-Ebene (Nginx) statt in WordPress konfigurieren? Ja, und das ist oft besser: Nginx-Level CORS-Header greifen vor WordPress und müssen nicht durch Plugin-Code laufen. Nginx-Konfiguration ist konsistenter und performanter. Allerdings kennt Nginx nicht die WordPress-spezifischen Anforderungen (welche Custom Headers WordPress braucht).

Warum erscheint der CORS-Fehler nur im Browser, nicht in Postman? Weil CORS nur Browser-seitig erzwungen wird. Postman, cURL und Server-seitiger Code ignorieren Access-Control-Allow-Origin-Header vollständig — sie implementieren keine Same-Origin-Policy.

Was ist CORS mit Credentials? Mit Access-Control-Allow-Credentials: true können Cookies und Auth-Header cross-origin gesendet werden. Das erfordert: exakter Origin-Match statt Wildcard, credentials: 'include' im Fetch-Call, und explizite Whitelisting der Origin.

Verwandte Begriffe

COEP · CORP · HTTP · HTTPS · REST API

CORS in drei Sätzen

CORS (Cross-Origin Resource Sharing) ist ein Browser-Sicherheitsmechanismus, der kontrolliert, welche Webseiten API-Anfragen an welche Server stellen dürfen. Ohne CORS würde die Same-Origin-Policy des Browsers jeden Cross-Origin-Request blockieren, bei dem Protokoll, Domain oder Port abweichen; CORS ist das server-gesteuerte Verfahren, diese Sperre selektiv aufzuheben. CORS greift ausschließlich browserseitig: Server-zu-Server-Kommunikation wie PHP-cURL-Aufrufe unterliegt ihm nicht. Der Browser unterscheidet Simple Requests, die direkt…

start call_