Wie kann ich CORS-Header setzen und wofür benötige ich diese?
Was ist CORS?
CORS ist eine empfehlende Richtline, welche durch zusätzliche HTTP-Header einem Browser mitteilt, dass ihm die Berechtigung erteilt wurde, auf ausgewählte Ressourcen eines anderen Server zuzugreifen. Der Cross-Origin-Request ist somit ein Scriptzugriff durch eine Webseite, um Daten von einem weiteren Server zu laden.
Einfaches Beispiel:
Eine HTML-Seite wird von einem Server über die Domain https://www.seite-eins.de bereitgestellt. Diese HTML-Seite enthält eine Script-Anweisung, welches eine Datei lädt, dessen URL auf einen anderen Server verweist https://www.seite-zwei.de/datei.zip. Dies wäre ein Cross-Origin-Request, welcher nur mit bestimmten CORS-Headern und Bedingungen ausgeführt wird.
Zugriffe dieser Art sind normalerweise durch die Same-Origin-Policy (SOP) untersagt, denn wer eine Website aufruft, sollte keine Daten von fremden Servern laden.
Was ist die SOP?
Die Same-Origin-Policy ist ein Sicherheitskonzept, welches verschiedenen Scriptsprachen wie zum Beispiel JavaScript verbietet, auf Daten zuzugreifen, welche von einer anderen Webseite stammen und deren Speicherort nicht dem gleichen Ursprung entsprechen. Sie stellt dadurch ein wesentliches Sicherheitselement zum Schutz des Anwenders vor Angriffen dar.
In diesen Fällen kommt dann CORS als Kompromiss zum Einsatz.
Wie setze ich CORS ein?
Um die gewünschten Header zu erzeugen, kannst du die Header in der .htaccess-Datei definieren und beim Aufruf der Domain übergeben. Hierbei ist darauf zu achten, CORS so restriktiv und limitierend einzusetzen wie möglich.
Die nachfolgenden Zeilen für deine .htaccess-Datei sollten für den Einsatzzweck nochmals angepasst und überprüft werden. Nicht alle Optionen sind eventuell nötig!
# CORS-HEADER Header set Access-Control-Allow-Origin "https://externe.quelle" Header set Access-Control-Allow-Methods "GET,PUT,POST,DELETE" Header set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"
Warum funktionieren die Header nicht auf Anhieb bei HostPress?
Unsere anspruchsvolle Server-Konfiguration, die sowohl Apache als auch Nginx umfasst, sowie das Caching und die Performance-Optimierung für Nginx führen dazu, dass bestimmte Header überschrieben werden. Im Kundencenter ermöglichen wir jedoch jedem Kunden, die gewünschten Anpassungen durch uns vornehmen zu lassen und diese mit unserer Konfiguration zu kombinieren.
Hierfür kannst du im Kundencenter die Security- / CORS-Header bestellen.
Addon abgelaufen oder nicht mehr buchbar – was tun?
Wenn du das Addon „Security- / CORS-Header“ bereits vor längerer Zeit gebucht hast, kann es sein, dass die Buchung inzwischen abgelaufen ist. In diesem Fall werden hinterlegte Header nicht mehr in der Serverkonfiguration berücksichtigt, auch wenn du sie uns erneut per Nachricht zukommen lässt.
Prüfe in diesem Fall Folgendes:
- Ist das Addon „Security- / CORS-Header“ aktuell noch aktiv in deinem Kundencenter gebucht?
- Liegt die letzte Einrichtung schon länger zurück (z. B. mehrere Jahre)? Dann lohnt sich eine kurze Rückfrage beim Support, ob eine Neubestellung nötig ist.
Falls das Addon abgelaufen ist, musst du es im Kundencenter neu buchen, bevor wir die gewünschten Header wieder in der Serverkonfiguration hinterlegen können.
So übermittelst du deinen Header richtig
Damit dein gewünschter Header schnell und ohne Rückfragen übernommen werden kann, gib ihn bitte als einzelne Zeile an – nicht in .htaccess-Syntax mit <IfModule>-Umgebung. Achte auf folgende Punkte:
- Kein
<IfModule mod_headers.c>-Rahmen verwenden. - Header-Name und Wert in einer Zeile angeben, z. B.:
Content-Security-Policy-Report-Only: default-src 'self'; ... - Die betroffene Domain mit angeben, für die der Header gesetzt werden soll.
So kann der Header direkt und ohne weitere Rückfragen in unsere Server-Konfiguration übernommen werden.
Authorization-Header für WordPress Application Passwords und die REST-API
Ein besonders häufiger Anwendungsfall für CORS- bzw. Header-Anpassungen ist die Nutzung von WordPress Application Passwords für den Zugriff über die REST-API – etwa um externen Tools, Redakteur-Zugängen oder KI-Integrationen kontrollierten Zugriff auf deine Website zu geben. Dabei tritt häufig der Fehler rest_not_logged_in auf, obwohl die Zugangsdaten korrekt sind.
Voraussetzungen
- Ein bereits angelegtes WordPress Application Password für den gewünschten Benutzer.
- Zugriff auf dein Kundencenter, um den Tarif- und Addon-Status zu prüfen.
Schritt-für-Schritt-Anleitung
Schritt 1: Ursache verstehen
Der Fehler rest_not_logged_in bei ansonsten korrekten Zugangsdaten bedeutet in der Regel, dass der Authorization-Header der Anfrage nicht bis zu WordPress durchgereicht wird. Das betrifft bei HostPress nicht nur klassische CORS-Anfragen, sondern grundsätzlich jede Authentifizierung über die REST-API, die auf diesem Header basiert – also auch Application Passwords.
Schritt 2: Warum die eigene .htaccess-Regel hier nicht ausreicht
Eigene Regeln wie SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 oder CGIPassAuth On in der .htaccess lösen dieses Problem bei HostPress in der Regel nicht zuverlässig. Grund ist unsere mehrstufige Serverkonfiguration aus Apache, Nginx und Caching, die solche Header-Werte nachträglich wieder überschreiben kann.
Schritt 3: Security-/CORS-Header-Addon prüfen und bestellen
Damit der Authorization-Header zuverlässig durchgereicht wird, muss die Anpassung direkt in unserer Serverkonfiguration hinterlegt werden. Das geschieht über das Security-/CORS-Header-Addon:
- Melde dich im Kundencenter an.
- Gehe zu „Produkte“ → „Verfügbare Addons anzeigen“.
- Suche dort nach dem Security-/CORS-Header-Addon und bestelle es.
Schritt 4: Wenn das Addon in deinem Tarif nicht auswählbar ist
Das Security-/CORS-Header-Addon ist aktuell nicht für jeden Tarif im Kundencenter direkt buchbar. Erscheint es bei dir nicht in der Addon-Liste, wende dich mit deinem Tarif und deinem Anwendungsfall (Application Passwords / REST-API-Zugriff) an den Support. Wir prüfen dann, ob und wie die Weiterleitung für deinen Tarif eingerichtet werden kann.
Support-Hinweis
Wenn WordPress Application Passwords oder andere REST-API-Zugriffe bei dir mit „rest_not_logged_in“ fehlschlagen, liegt es bei HostPress meist daran, dass der Authorization-Header serverseitig nicht durchgereicht wird. Eine eigene .htaccess-Regel reicht dafür in der Regel nicht aus – die zuverlässige Lösung ist das Security-/CORS-Header-Addon. Ist dieses in deinem Tarif nicht buchbar, melde dich einfach beim Support, wir klären das individuell mit dir.
Vor- und Nachteile von CORS
CORS dient also dazu, die grundsätzlich sichere Grundeinstellung Same-Origin-Policy zu umgehen. Die Same-Origin-Policy ist ein unerlässliches Mittel, um potenziell gefährliche Verbindungen zu unterbinden. Viele Verbindungen basieren aber auf solchen Cross-Origin-Requests und oftmals sind diese Verbindungen von einem Host zum anderen durchaus geplant und gewünscht.
CORS bietet somit einen sicheren Kompromiss für Situationen, bei welchen Cross-Origin-Requests ausdrücklich gewünscht sind. Durch falsche Einstellungen oder durch die Verwendung von WildCards besteht jedoch die Gefahr, jeglichen Schutz durch die SOP auszuhebeln. Es ist deshalb wichtig, darauf zu achten, Cross-Origin-Requests nur in ausgewählten Situationen einzusetzen und CORS so limitierend wie möglich zu konfigurieren.