WordPress „Cross-origin resource sharing (CORS) error“ beheben – Header korrekt konfigurieren

Du kennst das bestimmt: Du willst ein cooles WordPress-Plugin einbinden, ein externes Skript nachladen oder deine Website mit einer fancy API verbinden – und plötzlich knallt dir der Browser eine Fehlermeldung um die Ohren, die klingt wie ein Zauberspruch aus Harry Potter: „Cross-Origin Resource Sharing (CORS) error“. Herzlichen Glückwunsch, du bist im Club der Webentwickler:innen, die sich mit den Tücken moderner Websicherheit herumschlagen dürfen! Aber keine Sorge, wir von Nakaryu nehmen dich an die Hand und zeigen dir, wie du CORS-Fehler in WordPress nicht nur verstehst, sondern auch souverän behebst. Und das mit einer Prise Humor, einer ordentlichen Portion Fachwissen und – versprochen – ohne Bullshit-Bingo.

Bevor wir uns in die Tiefen der Header-Konfiguration stürzen, lass uns erstmal klären, was CORS eigentlich ist, warum es existiert und wieso es ausgerechnet bei WordPress-Websites so oft für Frust sorgt.

Was ist CORS überhaupt?

Stell dir vor, deine Website ist ein schickes Restaurant. Normalerweise dürfen nur die Gäste (Browser), die durch die Tür (gleiche Domain) kommen, auf die Speisekarte (Ressourcen) zugreifen. CORS ist der Türsteher, der entscheidet, ob auch Gäste von nebenan (andere Domains) einen Blick auf die Karte werfen dürfen. Das Ganze ist ein Sicherheitsmechanismus, der verhindern soll, dass bösartige Websites ungefragt Daten von deiner Seite abgreifen oder Aktionen im Namen deiner Nutzer:innen ausführen.

Technisch gesprochen: Cross-Origin Resource Sharing (CORS) ist ein Mechanismus, der Webbrowsern erlaubt, kontrolliert Ressourcen von einer anderen Domain (Origin) anzufordern. Standardmäßig blockiert der Browser solche Anfragen – es sei denn, der Server gibt explizit grünes Licht. Das passiert über spezielle HTTP-Header.

• Origin: Die Domain, von der die Anfrage kommt. Beispiel: Deine Website läuft auf meine-seite.de, aber du willst ein Skript von api.cooler-service.com laden.
• Resource: Das, was du anforderst – z.B. ein Bild, ein Skript, eine API-Response.
• Header: Die magischen Zeilen im HTTP-Protokoll, die dem Browser sagen: „Hey, das ist okay, du darfst das laden!“

Warum ist CORS so wichtig?

Ohne CORS könnten Websites beliebig Daten von anderen Seiten abgreifen – ein gefundenes Fressen für Angreifer. CORS schützt also vor Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF) und ist damit ein zentraler Baustein moderner Websicherheit (MDN Web Docs).

WordPress und CORS: Warum kracht es so oft?

WordPress ist das beliebteste Content-Management-System der Welt – laut W3Techs laufen über 43% aller Websites damit. Die Kehrseite: Viele Plugins, Themes und externe Dienste wollen Daten austauschen. Und genau hier kommt CORS ins Spiel. Typische Szenarien, in denen CORS-Fehler auftreten:

• AJAX-Requests an externe APIs: Du nutzt ein Plugin, das Daten von einer anderen Domain abruft (z.B. Wetter, Social Media, Zahlungsanbieter).
• CDN-Einbindung: Deine Bilder, Skripte oder Stylesheets liegen auf einem Content Delivery Network (CDN) – und der Browser blockt sie.
• Headless WordPress: Du nutzt WordPress als Backend und ein separates Frontend (z.B. mit React oder Vue) – und die Kommunikation läuft über die REST-API.
• Webfonts oder externe Ressourcen: Google Fonts, Adobe Fonts oder andere externe Ressourcen werden nicht geladen.

Die Fehlermeldung sieht dann meist so aus:


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


Oder auf Deutsch: „Du kommst hier nicht rein!“

Wie funktioniert CORS technisch?

Wenn dein Browser eine Anfrage an eine andere Domain schickt, prüft er, ob der Server den Zugriff erlaubt. Das passiert über folgende Header:

Fehlt einer dieser Header oder ist falsch konfiguriert, blockt der Browser die Anfrage – und du siehst den berüchtigten CORS-Fehler.

Wie behebst du CORS-Fehler in WordPress?

Jetzt wird’s praktisch! Es gibt verschiedene Wege, CORS-Header korrekt zu setzen – je nachdem, wie dein Server konfiguriert ist und was du genau erreichen willst. Hier die wichtigsten Methoden, ausführlich erklärt:

• 1. CORS-Header in der .htaccess setzen (Apache)

  Die .htaccess-Datei ist das Schweizer Taschenmesser für Apache-Server. Hier kannst du CORS-Header global oder für bestimmte Verzeichnisse setzen. Beispiel:

  
<IfModule mod_headers.c>
  Header set Access-Control-Allow-Origin "https://meine-seite.de"
  Header set Access-Control-Allow-Methods "GET, POST, OPTIONS"
  Header set Access-Control-Allow-Headers "Content-Type, Authorization"
</IfModule>


  Wichtig: Ersetze https://meine-seite.de durch deine Domain. Für mehrere Domains musst du ein bisschen tricksen (z.B. mit RewriteCond oder dynamischen Headern).

• 2. CORS-Header in functions.php (WordPress)

  Du kannst CORS-Header auch direkt in deinem Theme oder einem Custom-Plugin setzen. Das ist besonders praktisch, wenn du nur bestimmte Endpunkte (z.B. die REST-API) freigeben willst:

  
add_action( 'init', function() {
  if ( isset( $_SERVER['HTTP_ORIGIN'] ) && $_SERVER['HTTP_ORIGIN'] === 'https://meine-seite.de' ) {
    header( 'Access-Control-Allow-Origin: https://meine-seite.de' );
    header( 'Access-Control-Allow-Methods: GET, POST, OPTIONS' );
    header( 'Access-Control-Allow-Headers: Content-Type, Authorization' );
  }
});


  Achtung: Diese Methode ist nicht für statische Ressourcen (Bilder, Fonts) geeignet, sondern für dynamische Endpunkte wie die REST-API.

• 3. CORS-Header in nginx konfigurieren

  Falls du nginx nutzt, kannst du die Header in der Server-Konfiguration setzen:

  
location / {
  add_header 'Access-Control-Allow-Origin' 'https://meine-seite.de';
  add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
  add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
}


  Nach Änderungen nginx neu starten nicht vergessen!

• 4. CORS-Header für bestimmte Dateitypen (z.B. Fonts, Bilder)

  Manchmal willst du nur bestimmte Ressourcen freigeben, z.B. Webfonts. Das geht in der .htaccess so:

  
<FilesMatch ".(ttf|otf|eot|woff|woff2)$">
  Header set Access-Control-Allow-Origin "*"
</FilesMatch>


  Hinweis: Das Sternchen (*) erlaubt den Zugriff von allen Domains – das ist für Fonts meist okay, für APIs aber ein Sicherheitsrisiko!

• 5. Preflight-Requests (OPTIONS) korrekt behandeln

  Bei komplexeren Anfragen (z.B. mit Custom-Headern oder Methoden wie PUT/DELETE) schickt der Browser einen sogenannten Preflight-Request mit der Methode OPTIONS. Dein Server muss darauf antworten, sonst gibt’s einen CORS-Fehler. Beispiel für Apache:

  
<IfModule mod_headers.c>
  Header always set Access-Control-Allow-Origin "https://meine-seite.de"
  Header always set Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE"
  Header always set Access-Control-Allow-Headers "Content-Type, Authorization"
</IfModule>


  Und für nginx:

  
if ($request_method = 'OPTIONS') {
  add_header 'Access-Control-Allow-Origin' 'https://meine-seite.de';
  add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
  add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
  return 204;
}


• 6. CORS-Header testen und debuggen

  Nach der Konfiguration solltest du testen, ob die Header korrekt gesetzt werden. Das geht z.B. mit den DevTools deines Browsers (Netzwerk-Tab) oder mit Tools wie test-cors.org oder curl:

  
curl -I -H "Origin: https://meine-seite.de" https://api.cooler-service.com/data


  Im Response sollten die richtigen Access-Control-Allow-*-Header auftauchen.

Best Practices und Sicherheitstipps

• Nie * für APIs verwenden! Das erlaubt jedem den Zugriff – ein No-Go für sensible Daten.
• Nur die Domains freigeben, die wirklich Zugriff brauchen. Am besten per Whitelist.
• Regelmäßig testen und Logs prüfen. Gerade nach Plugin-Updates oder Serverumzügen können sich CORS-Header ändern.
• Bei REST-APIs: Authentifizierung nicht vergessen! CORS ist kein Ersatz für Login, Tokens oder andere Sicherheitsmechanismen.

Typische Stolperfallen bei WordPress und CORS

• CDN falsch konfiguriert: Viele CDNs setzen eigene Header oder überschreiben deine Einstellungen. Prüfe die CDN-Konsole!
• Cache-Plugins: Manche Caching-Plugins strippen Header aus der Response. Teste mit und ohne aktiviertes Caching.
• Mehrere Domains/Subdomains: Wenn du z.B. www und ohne-www nutzt, müssen beide als Origin erlaubt sein.
• HTTPS vs. HTTP: Der Origin-Header unterscheidet zwischen https:// und http:// – immer beide Varianten prüfen!

Fazit: CORS ist kein Hexenwerk – aber ein bisschen Magie braucht’s schon

Mit dem richtigen Know-how und ein paar gezielten Handgriffen kannst du CORS-Fehler in WordPress schnell und sicher beheben. Wichtig ist, dass du verstehst, warum der Fehler auftritt, wo du die Header setzen musst und wie du sie testest. Dann steht der reibungslosen Integration externer Dienste, APIs und Ressourcen nichts mehr im Weg – und deine Website bleibt sicher und performant.

Falls du keine Lust hast, dich mit Headern, Serverkonfiguration und Debugging herumzuschlagen, gibt’s natürlich eine entspannte Lösung: Lass uns von Nakaryu ran! Wir kümmern uns nicht nur um CORS, sondern um alles, was deine WordPress-Website braucht – von Design über Performance bis zu Sicherheit und DSGVO. Schau dir unsere Webdesign-Flatrate an und hol dir ein Team, das Technik und Ästhetik liebt. Wir machen das für dich – und du kannst dich auf das konzentrieren, was du am besten kannst.

Quellen

• MDN Web Docs: Cross-Origin Resource Sharing (CORS)
• W3Techs: Usage statistics and market share of WordPress
• Smashing Magazine: A Guide To CORS
• test-cors.org
• curl – Command Line Tool and Library