Du kennst das bestimmt: Du willst mit deiner WordPress-Website so richtig durchstarten, vielleicht eine schicke React-App anbinden, ein paar Daten per REST-API austauschen oder einfach nur ein cooles Plugin nutzen – und plötzlich knallt dir der Browser eine dieser legendären Fehlermeldungen um die Ohren: „405 Method Not Allowed“ oder „403 Forbidden“. Herzlichen Glückwunsch, du bist im exklusiven Club der REST-API-Fehler gelandet! Aber keine Sorge, ich nehme dich heute mit auf eine Reise durch die Untiefen von CORS, ModSecurity, .htaccess und all den anderen Stolpersteinen, die zwischen dir und einer funktionierenden WordPress-REST-API stehen. Und ja, es wird nerdig, aber auch unterhaltsam – versprochen!

Bevor wir uns in die technischen Details stürzen, lass uns kurz klären, warum das Thema überhaupt so wichtig ist. Die WordPress REST API ist seit Version 4.7 fester Bestandteil von WordPress und ermöglicht es, Inhalte und Funktionen deiner Website über standardisierte HTTP-Anfragen (GET, POST, PUT, DELETE) zu steuern. Das ist nicht nur für Entwickler:innen spannend, sondern auch für alle, die moderne Webanwendungen, Mobile Apps oder Integrationen mit anderen Systemen bauen wollen. Laut W3Techs läuft mittlerweile über 43% aller Websites weltweit auf WordPress – und die REST API ist das Tor zur Zukunftsfähigkeit dieser Plattform.

Doch wie so oft im Leben gilt: Wo viel Licht ist, ist auch viel Schatten. Die REST API ist ein beliebtes Ziel für Angriffe, und deshalb greifen viele Hoster, Firewalls und Sicherheitsplugins rigoros durch. Das Ergebnis: harmlos gemeinte Anfragen werden blockiert, und du bekommst kryptische Fehlermeldungen serviert. Zeit, das zu ändern!

• Was bedeutet „405 Method Not Allowed“?

  Diese Fehlermeldung taucht auf, wenn du eine HTTP-Methode (z.B. POST, PUT, DELETE) verwendest, die vom Server oder der API nicht akzeptiert wird. Das kann verschiedene Ursachen haben: Die Methode ist auf dem Server nicht erlaubt, die .htaccess-Datei blockiert sie, oder ein Sicherheitsmodul wie ModSecurity schlägt Alarm. Besonders häufig passiert das bei Custom-APIs, AJAX-Requests oder wenn du mit Tools wie Postman experimentierst.

• Was steckt hinter „403 Forbidden“?

  Hier wird’s noch gemeiner: Der Server hat deine Anfrage zwar verstanden, will sie aber aus Sicherheitsgründen nicht ausführen. Das kann an fehlenden Berechtigungen, fehlerhaften CORS-Einstellungen, restriktiven Firewalls oder auch an falsch konfigurierten Plugins liegen. Besonders tückisch: Manchmal bekommst du den 403-Fehler nur bei bestimmten Endpunkten oder Methoden – und suchst dir dann stundenlang einen Wolf.

Bevor wir uns an die Lösung machen, ein kleiner Überblick über die häufigsten Ursachen – und wie du sie systematisch aufspürst:

1. CORS – Cross-Origin Resource Sharing

Stell dir vor, deine Website läuft auf meine-seite.de, aber deine App oder ein externer Service will Daten von api.meine-seite.de holen. Der Browser sagt: „Moment mal, das ist eine andere Domain – das ist mir nicht geheuer!“ Und schon blockiert er die Anfrage. Das nennt sich CORS (Cross-Origin Resource Sharing) und ist ein Sicherheitsmechanismus, der verhindern soll, dass böse Websites Schindluder mit deiner API treiben.

• Typische CORS-Fehler:

  Im Browser-Console-Log findest du dann Meldungen wie No 'Access-Control-Allow-Origin' header is present oder Request header field X is not allowed by Access-Control-Allow-Headers. Besonders bei POST-, PUT- oder DELETE-Requests wird oft ein sogenannter Preflight-Request (OPTIONS) gesendet, der ebenfalls blockiert werden kann.

• Lösung: CORS-Header setzen

  Du kannst CORS-Header entweder serverseitig (z.B. in der .htaccess) oder per Plugin setzen. Beispiel für die .htaccess:

  
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE"
Header set Access-Control-Allow-Headers "Content-Type, Authorization"
</IfModule>


  Achtung: Das Sternchen (*) erlaubt alle Domains – für produktive Umgebungen solltest du hier gezielt deine Domain eintragen!

• WordPress-Plugins für CORS:

  Es gibt Plugins wie WP CORS oder CORS, die dir das Setzen der Header erleichtern. Aber: Weniger ist oft mehr – prüfe, ob du wirklich ein Plugin brauchst oder es direkt im Server-Setup lösen kannst.

2. ModSecurity – Der Server-Bodyguard

Viele Hoster setzen ModSecurity ein, ein Open-Source-Web Application Firewall (WAF) Modul für Apache und Nginx. Es schützt vor Angriffen wie SQL-Injection, XSS und Co. – aber manchmal ist ModSecurity etwas übereifrig und blockiert auch legitime REST-API-Requests.

• Typische ModSecurity-Probleme:

  Du bekommst 403 oder 405 Fehler, oft ohne weitere Erklärung. Im Server-Error-Log findest du dann Einträge wie ModSecurity: Access denied with code 403 oder ModSecurity: Request body access denied. Besonders betroffen sind PUT/DELETE-Requests oder Anfragen mit bestimmten Headern.

• Lösung: ModSecurity-Regeln anpassen

  Hier gibt es mehrere Wege:

  • Sprich mit deinem Hoster! Viele bieten die Möglichkeit, ModSecurity temporär zu deaktivieren oder einzelne Regeln auszuschließen.
  • Setze in der .htaccess gezielt Ausnahmen für die REST-API:
    
<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>


    Wichtig: Das deaktiviert ModSecurity für den gesamten Ordner – also nur im Notfall und niemals dauerhaft in der Produktion!

  • Nutze eigene ModSecurity-Regeln, um nur bestimmte Endpunkte freizugeben. Das ist allerdings fortgeschritten und erfordert SSH-Zugang und Know-how.

3. .htaccess – Die geheime Schaltzentrale

Die .htaccess-Datei ist das Schweizer Taschenmesser für Apache-Webserver. Hier kannst du Weiterleitungen, Zugriffsbeschränkungen und eben auch HTTP-Methoden steuern. Ein häufiger Fehler: Die .htaccess blockiert Methoden wie PUT oder DELETE, die für die REST-API aber notwendig sind.

• Methoden explizit erlauben:

  Füge folgende Zeile in deine .htaccess ein, um die wichtigsten Methoden freizugeben:

  
<LimitExcept GET POST OPTIONS PUT DELETE>
Deny from all
</LimitExcept>


  Oder noch besser, gar keine Limitierung setzen, wenn du REST-API intensiv nutzt.

• Rewrite-Regeln prüfen:

  WordPress nutzt eigene Rewrite-Regeln für „schöne“ Permalinks. Fehlerhafte oder doppelte Regeln können REST-API-Endpunkte unzugänglich machen. Prüfe, ob deine .htaccess so aussieht:

  
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress


  Fehlt hier etwas oder gibt es zusätzliche Regeln, kann das REST-API-Probleme verursachen.

4. WordPress- und Plugin-Security

Auch WordPress selbst und viele Security-Plugins (z.B. Wordfence, iThemes Security) blockieren REST-API-Endpunkte, um Angriffe zu verhindern. Das ist grundsätzlich sinnvoll, kann aber zu unerwarteten 403-Fehlern führen.

• REST-API-Freigaben prüfen:

  Viele Plugins bieten Einstellungen, um die REST-API gezielt freizugeben oder einzuschränken. Prüfe die Plugin-Dokumentation und die Einstellungen im Backend.

• Benutzerrechte und Nonces:

  WordPress prüft bei sensiblen Endpunkten, ob der User angemeldet ist und die richtigen Rechte hat. Bei Custom-APIs solltest du immer wp_nonce und current_user_can() nutzen, um Berechtigungen sauber zu prüfen.

• Debugging-Tipp:

  Nutze das Plugin Query Monitor, um REST-API-Fehler und Berechtigungsprobleme schnell zu identifizieren.

5. Systematische Fehlersuche – So gehst du vor

• 1. Browser-Konsole und Netzwerkanalyse:

  Schau dir die Fehlermeldungen im Browser an. Welche Methode wird blockiert? Gibt es CORS-Fehler?

• 2. Server-Logs checken:

  Im Apache- oder Nginx-Error-Log findest du oft Hinweise auf ModSecurity oder .htaccess-Probleme.

• 3. Plugins und Themes deaktivieren:

  Deaktiviere testweise alle Plugins und wechsle auf ein Standard-Theme. Funktioniert die REST-API dann, liegt es an einem Plugin oder Theme.

• 4. .htaccess und CORS-Header prüfen:

  Vergleiche deine .htaccess mit der Standardversion und setze die CORS-Header korrekt.

• 5. Hoster kontaktieren:

  Manche Probleme (z.B. ModSecurity) kannst du nur mit Hilfe deines Hosters lösen. Schicke ihnen die genaue Fehlermeldung und bitte um Anpassung der Regeln.

6. Best Practices für eine sichere und funktionierende REST-API

• Nur notwendige Methoden und Endpunkte freigeben:

  Öffne nicht die ganze API für die Welt, sondern nur das, was du wirklich brauchst. Nutze Authentifizierung und prüfe Berechtigungen.

• Regelmäßige Updates:

  Halte WordPress, Plugins und Server-Software aktuell, um Sicherheitslücken zu vermeiden.

• Monitoring und Logging:

  Überwache die REST-API auf ungewöhnliche Zugriffe und Fehler. Tools wie ELK Stack oder Datadog helfen beim Monitoring.

• Backups nicht vergessen:

  Im Fall der Fälle solltest du immer ein aktuelles Backup parat haben – am besten automatisiert und extern gespeichert.

Fazit: REST-API-Fehler sind nervig – aber lösbar!

Ob CORS, ModSecurity, .htaccess oder ein übermotiviertes Security-Plugin – die Ursachen für „405 Method Not Allowed“ und „403 Forbidden“ bei der WordPress REST API sind vielfältig, aber mit etwas Geduld und systematischer Fehlersuche fast immer in den Griff zu bekommen. Und falls du mal gar nicht weiterkommst, gibt’s ja noch uns von Nakaryu!

Wir sind nicht nur WordPress-Nerds, sondern echte Problemlöser:innen – und helfen dir gerne, deine Website sicher, schnell und zukunftsfähig zu machen. Egal ob REST-API, WooCommerce, Performance oder Design: Hier geht’s zu unserem Webdesign-Service – individuell, flexibel und mit persönlichem Support. Lass uns gemeinsam das Web ein bisschen besser machen!

Quellen

• W3Techs: WordPress Usage Statistics
• WordPress Developer Resources: REST API Handbook
• MDN Web Docs: CORS
• ModSecurity: Open Source Web Application Firewall
• WP CORS Plugin
• Query Monitor Plugin
• Apache Lounge: .htaccess and HTTP Methods