WordPress REST API Fehler beheben: 404, 403 und

Zuletzt aktualisiert: 28. August 2026

Quick Answer: Die häufigsten Ursachen für WordPress REST API Fehler in Headless-Setups sind keine Bugs im Code, sondern Konfigurationsprobleme: falsche Permalink-Einstellungen, blockierende Security-Plugins, WAF-Regeln und fehlerhafte CORS-Header. Ein 404 auf /wp-json/ zeigt fast immer, dass Rewrite-Regeln die Route nicht korrekt an index.php weiterleiten. Ein 403 kommt typischerweise von ModSecurity, Wordfence oder einem CDN, das JSON-Traffic blockiert. Authentifizierungsfehler entstehen durch abgelaufene Tokens, fehlende Application Passwords oder falsch konfigurierte JWT-Plugins.

Key Takeaways

🔧 404 auf /wp-json/ bedeutet fast immer: Permalinks zurücksetzen oder .htaccess/Nginx-Rewrite-Regeln korrigieren.
🚫 403 Forbidden kommt überwiegend von Security-Plugins (Wordfence, iThemes) oder WAF/ModSecurity-Regeln, nicht von WordPress selbst.
🔑 Authentifizierungsfehler (401/403, rest_forbidden) entstehen durch falsche Tokens, abgelaufene Nonces oder fehlende HTTPS-Verbindung.
🌐 CORS-Fehler bei Headless-Frontends (React, Next.js) lassen sich mit einem rest_pre_serve_request-Filter und gezielten CDN-Ausnahmen lösen.
🛡️ Sicherheit 2026: Kritische REST-API-Lücken (u.a. CVE-2026-63030) erfordern sofortiges Update auf WordPress 6.8.6, 6.9.5 oder 7.0.2 [4][6].
⚙️ JWT vs. Application Passwords: JWT eignet sich für SPAs und externe Frontends, Application Passwords für Server-zu-Server-Kommunikation.
🧪 Diagnose-Tipp: curl -I https://deine-domain.tld/wp-json/ direkt auf dem Server ausführen und mit dem lokalen Ergebnis vergleichen, um Firewall/CDN-Probleme zu isolieren.
📋 Berechtigungen: Capability-Checks und minimale Rechtevergabe bei App-Passwörtern sind die wichtigsten Schutzmaßnahmen für offene Headless-APIs.

Was ist die WordPress REST API und wie funktioniert sie bei Headless-Setups?

Die WordPress REST API ist eine standardisierte Schnittstelle, über die externe Anwendungen Daten aus WordPress lesen und schreiben können, ohne das klassische Theme-System zu nutzen. Bei Headless-Setups übernimmt WordPress nur die Rolle des Content-Backends, während ein separates Frontend (React, Next.js, Vue, Nuxt) die Darstellung übernimmt.

KI-generiertes Bild

Wie das technisch funktioniert:

Alle API-Endpunkte sind unter /wp-json/ erreichbar, z.B. /wp-json/wp/v2/posts für Beiträge.
Das Frontend sendet HTTP-Anfragen (GET, POST, PUT, DELETE) an diese Endpunkte.
WordPress antwortet mit JSON-Daten, die das Frontend dann rendert.
Öffentliche Endpunkte sind ohne Authentifizierung erreichbar; Schreib-Operationen und geschützte Daten erfordern eine gültige Authentifizierung [7].

Warum Headless-Setups fehleranfälliger sind:

Bei klassischen WordPress-Seiten läuft alles auf demselben Server und im selben Ursprung. Bei Headless-Setups kommen Cross-Origin-Anfragen (CORS), externe Token-Verwaltung und oft ein CDN oder WAF dazwischen, was die Fehlerquellen deutlich erhöht [2][3]. Wer bereits Erfahrung mit WordPress-Fehlern professionell beheben hat, kennt dieses Muster: Viele Probleme entstehen nicht im Code, sondern in der Infrastruktur drumherum.

Warum bekomme ich 404-Fehler bei WordPress REST API-Aufrufen?

Ein 404-Fehler auf /wp-json/ bedeutet fast immer, dass der Webserver die Anfrage nicht an WordPress weiterleitet. Das ist kein WordPress-Bug, sondern ein Server-Konfigurationsproblem [1][5].

Die häufigsten Ursachen:

Ursache	Symptom	Lösung
Permalinks nicht gespeichert	Alle `/wp-json/`-Pfade liefern 404	Einstellungen → Permalinks → Speichern
Fehlende `.htaccess`-Rewrite-Regeln	Apache leitet nicht an `index.php` weiter	`.htaccess` neu generieren
Nginx ohne `try_files`-Regel	Nginx findet Route nicht	Nginx-Config anpassen
Security-Plugin blockiert Route	Gezielt `/wp-json/` gibt 404 zurück	Plugin-Einstellungen prüfen

Schritt-für-Schritt-Diagnose für 404:

Permalinks zurücksetzen: Im WordPress-Backend unter Einstellungen → Permalinks einfach auf „Speichern“ klicken, ohne etwas zu ändern. Das regeneriert die .htaccess-Datei.

.htaccess prüfen: Die Datei im WordPress-Stammverzeichnis sollte den Standard-WordPress-Block enthalten:

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

Nginx-Konfiguration: Bei Nginx muss try_files $uri $uri/ /index.php?$args; im Server-Block vorhanden sein [5].
curl-Test: curl -I https://deine-domain.tld/wp-json/ direkt auf dem Server ausführen. Wenn der Server 200 zurückgibt, der Browser aber 404, liegt das Problem am CDN oder einer Firewall [1][5].

Häufiger Fehler: Viele Entwickler suchen den Fehler im Code, obwohl ein einfaches Permalink-Reset das Problem in 30 Sekunden löst.

Wie behebe ich 403 Forbidden-Fehler in der WordPress REST API?

Ein 403-Fehler bedeutet, dass der Zugriff aktiv blockiert wird, meistens nicht von WordPress selbst, sondern von einer vorgelagerten Sicherheitsebene [1][5].

KI-generiertes Bild

Typische Verursacher von 403:

Wordfence: Die Option „Block invalid REST API requests“ blockiert Anfragen von externen Frontends.
iThemes Security / Solid Security: Kann REST-API-Zugriff für nicht eingeloggte Nutzer sperren.
ModSecurity: WAF-Regeln blockieren oft JSON-Inhalte oder unbekannte User-Agent-Header.
Cloudflare / CDN-Firewall: Regeln gegen POST-Requests auf /wp-json/ sind häufig.

Lösung für Security-Plugins:

Bei Wordfence: Wordfence → Firewall → Manage Firewall → Whitelist und /wp-json/* als Ausnahme eintragen. Alternativ die Option „Allow authorized REST API requests“ aktivieren [1][5].

Lösung für ModSecurity:

ModSecurity-Logs prüfen (meist unter /var/log/apache2/modsec_audit.log). Wenn eine Regel /wp-json/ blockiert, diese Regel für den Pfad deaktivieren oder beim Hosting-Anbieter eine Ausnahme beantragen [1].

Diagnose-Befehl:

<code class="language-bash">curl -v -H "Content-Type: application/json" https://deine-domain.tld/wp-json/wp/v2/posts
</code>

Ein 403 mit einem X-Mod-Security oder X-Firewall-Header im Response zeigt, wo der Block sitzt.

Ähnliche Infrastrukturprobleme entstehen übrigens auch bei WordPress SSL-Fehlern, wo HTTPS-Konfigurationen API-Calls blockieren können.

WordPress REST API-Authentifizierung mit JWT-Token einrichten

JWT (JSON Web Token) ist die empfohlene Authentifizierungsmethode für Headless-Frontends, die im Browser laufen. Ein JWT-Token wird einmalig ausgestellt und bei jeder Anfrage im Authorization-Header mitgesendet [10].

Einrichtung Schritt für Schritt:

Plugin installieren: JWT Authentication for WP REST API oder Simple JWT Login.

In der wp-config.php einen geheimen Schlüssel definieren:

define('JWT_AUTH_SECRET_KEY', 'dein-geheimer-schlüssel');
define('JWT_AUTH_CORS_ENABLE', true);

Token anfordern via POST an /wp-json/jwt-auth/v1/token mit Benutzername und Passwort.
Token im Frontend speichern (nicht im localStorage bei sensiblen Daten, besser httpOnly-Cookie).
Bei jeder API-Anfrage den Header setzen: Authorization: Bearer <token> [10].

Häufige JWT-Fehler und Lösungen:

jwt_auth_invalid_token: Token ist abgelaufen oder der geheime Schlüssel wurde geändert → neues Token anfordern.
jwt_auth_no_auth_header: Der Authorization-Header wird vom Server gestripped → in .htaccess oder Nginx-Config explizit durchleiten:
```
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
```
Zeitdrift: Wenn Server- und Client-Zeit mehr als ein paar Minuten abweichen, schlägt die Token-Validierung fehl → NTP auf dem Server prüfen [10].

Unterschied zwischen JWT und Basic Auth bei der WordPress REST API

JWT und Application Passwords (Basic Auth) lösen dasselbe Problem auf unterschiedliche Weise. Die Wahl hängt vom Anwendungsfall ab [7][10].

KI-generiertes Bild

Entscheidungshilfe:

JWT wählen, wenn: Ein Browser-Frontend (React, Next.js, Vue) direkt mit der API kommuniziert, Benutzer sich einloggen müssen und Tokens nach kurzer Zeit ablaufen sollen.
Application Passwords wählen, wenn: Server-zu-Server-Kommunikation stattfindet (z.B. ein Node.js-Backend ruft WordPress ab), kein Browser involviert ist und HTTPS garantiert ist.
Cookie + Nonce wählen, wenn: Das Frontend im selben WordPress-Kontext läuft (z.B. ein Gutenberg-Block oder ein Admin-UI) [7].

Sicherheitsunterschiede:

Methode	Ablaufzeit	Browser-sicher	Server-zu-Server
JWT	Konfigurierbar (z.B. 1h)	Ja (mit Vorsicht)	Ja
Application Passwords	Kein Ablauf	Nein (Passwort im Header)	Ja
Cookie + Nonce	Session-basiert	Ja	Nein

Wichtig: Application Passwords niemals im Browser-Frontend verwenden. Das Passwort wäre im JavaScript-Code sichtbar und könnte gestohlen werden.

WordPress REST API CORS-Fehler bei Headless-Frontends lösen

CORS-Fehler entstehen, wenn das Frontend auf einer anderen Domain läuft als WordPress und der Server den Access-Control-Allow-Origin-Header nicht korrekt setzt. Das ist der häufigste Fehler bei frisch eingerichteten Headless-Setups [2][3].

KI-generiertes Bild

Symptom: Der Browser zeigt: Access to fetch at 'https://cms.deine-domain.de/wp-json/...' from origin 'https://frontend.deine-domain.de' has been blocked by CORS policy.

Lösung via WordPress-Filter (empfohlen):

<code class="language-php">add_filter('rest_pre_serve_request', function($value) {
    $allowed_origin = 'https://dein-frontend.de';
    $origin = $_SERVER['HTTP_ORIGIN'] ?? '';
    
    if ($origin === $allowed_origin) {
        header('Access-Control-Allow-Origin: ' . $allowed_origin);
        header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS');
        header('Access-Control-Allow-Headers: Authorization, Content-Type, X-WP-Nonce');
        header('Access-Control-Allow-Credentials: true');
    }
    return $value;
});
</code>

Diesen Code in die functions.php des aktiven Themes oder in ein eigenes Plugin einfügen [2][3].

Preflight-Requests (OPTIONS) nicht vergessen:

Browser senden vor POST/PUT-Anfragen einen OPTIONS-Preflight. WordPress beantwortet diesen standardmäßig nicht korrekt. Lösung: In der Nginx-Config oder .htaccess OPTIONS-Requests explizit behandeln:

<code class="language-nginx">if ($request_method = 'OPTIONS') {
    add_header 'Access-Control-Allow-Origin' 'https://dein-frontend.de';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
    add_header 'Access-Control-Max-Age' 1728000;
    return 204;
}
</code>

CDN-Einstellungen: Bei Cloudflare unter Rules → Transform Rules eine Regel erstellen, die für /wp-json/* den Access-Control-Allow-Origin-Header hinzufügt [3].

WordPress REST API-Endpunkte nicht verfügbar: Berechtigungen und Rollen konfigurieren

Wenn ein Endpunkt 403 zurückgibt, obwohl die Authentifizierung korrekt ist, fehlen dem Benutzer die nötigen WordPress-Capabilities. Das ist ein Berechtigungsproblem, kein Authentifizierungsproblem [8][10].

Fehlercode-Übersicht:

rest_forbidden: Benutzer ist authentifiziert, hat aber nicht die nötige Berechtigung.
rest_cannot_create: Benutzer darf keine Beiträge erstellen.
rest_cookie_invalid_nonce: Nonce ist abgelaufen oder ungültig.
rest_no_route: Die Route existiert nicht (oft nach Plugin-Deaktivierung).

Capabilities und Rollen prüfen:

<code class="language-php">// Prüfen, welche Capabilities ein Benutzer hat
$user = wp_get_current_user();
var_dump($user->allcaps);
</code>

Minimale Rechte für häufige Operationen:

Beiträge lesen (öffentlich): Keine Authentifizierung nötig.
Beiträge erstellen: publish_posts-Capability (Autor-Rolle oder höher).
Benutzer verwalten: list_users-Capability (Administrator).
Optionen lesen/schreiben: manage_options (Administrator).

Tipp: Application Passwords immer mit dem kleinstmöglichen Benutzerrecht anlegen. Für ein Headless-Frontend, das nur liest, reicht ein Abonnenten-Konto für öffentliche Inhalte aus [7].

Ähnliche Berechtigungsprobleme entstehen auch bei WordPress Plugin-Fehlern, wenn Plugins Capabilities überschreiben.

WordPress REST API mit Next.js oder React verbinden: Typische Fehler

Next.js und React sind die beliebtesten Headless-Frontends für WordPress. Die Verbindung scheitert meistens an drei Stellen: CORS, Authentifizierung und Cache-Invalidierung [2][3].

Häufige Fehler und direkte Lösungen:

1. fetch schlägt in Next.js fehl (serverseitig): Serverseitige Requests in Next.js (getStaticProps, getServerSideProps, App Router fetch) laufen auf dem Server, nicht im Browser. CORS-Fehler entstehen hier nicht, aber Firewall-Regeln, die bestimmte IP-Adressen oder User-Agents blockieren, können Probleme verursachen. Lösung: Den User-Agent des Next.js-Servers in der WAF-Whitelist eintragen.

2. Client-seitige Requests schlagen fehl: Hier entstehen CORS-Fehler. Lösung wie oben beschrieben: rest_pre_serve_request-Filter in WordPress.

3. Statische Seiten zeigen veraltete Daten: Bei getStaticProps mit revalidate werden Seiten gecacht. Wenn WordPress-Inhalte sich ändern, muss ein Webhook die Next.js-Revalidierung auslösen. Das REST API-Plugin WP Webhooks kann bei Beitrags-Updates automatisch einen Next.js-Revalidierungs-Endpoint aufrufen.

4. Authentifizierte Requests im Browser: Für Benutzer-spezifische Inhalte (z.B. WooCommerce-Warenkorb) JWT verwenden und den Token sicher im httpOnly-Cookie speichern, nicht im localStorage.

WordPress Nonce und REST API-Sicherheit implementieren

Nonces sind einmalige Tokens, die WordPress für same-origin Requests verwendet. Sie sind kein Ersatz für JWT oder Application Passwords, sondern eine zusätzliche Sicherheitsebene für Admin-UIs und Gutenberg-Blöcke [7].

Nonce in WordPress generieren:

<code class="language-php">wp_localize_script('mein-script', 'wpApiSettings', [
    'root' => esc_url_raw(rest_url()),
    'nonce' => wp_create_nonce('wp_rest'),
]);
</code>

Nonce im JavaScript verwenden:

<code class="language-javascript">fetch('/wp-json/wp/v2/posts', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-WP-Nonce': wpApiSettings.nonce,
    },
    body: JSON.stringify({ title: 'Neuer Beitrag', status: 'publish' }),
});
</code>

Wichtig: Nonces laufen nach 12-24 Stunden ab. Bei Single-Page-Apps, die lange im Browser geöffnet bleiben, muss die Nonce periodisch erneuert werden. Fehler rest_cookie_invalid_nonce ist fast immer ein Ablauf-Problem.

Wann sollte die WordPress REST API aus Sicherheitsgründen eingeschränkt werden?

Die REST API komplett zu deaktivieren ist in 2026 keine empfohlene Strategie mehr, da viele WordPress-Core-Funktionen (Gutenberg, Block Editor) darauf angewiesen sind. Sinnvoller ist eine gezielte Einschränkung [7].

Sinnvolle Einschränkungen:

Anonymen Zugriff auf Benutzer-Endpunkte blockieren: /wp-json/wp/v2/users gibt standardmäßig Benutzernamen preis. Lösung:

add_filter('rest_endpoints', function($endpoints) {
    if (!is_user_logged_in()) {
        unset($endpoints['/wp/v2/users']);
        unset($endpoints['/wp/v2/users/(?P<id>[d]+)']);
    }
    return $endpoints;
});

Schreib-Operationen nur für authentifizierte Requests: Nie edit_posts oder publish_posts für anonyme Benutzer freigeben.
Batch-Route überwachen: Im Sommer 2026 wurden kritische Lücken in der Batch-Route (/wp-json/batch/v1) entdeckt (CVE-2026-63030), die unauthentifizierte Code-Ausführung ermöglichten [4][6][9]. Sofortiges Update auf WordPress 6.8.6, 6.9.5 oder 7.0.2 ist Pflicht.

Mehr zu WordPress-Sicherheitslücken und deren Behebung gibt es im Artikel WordPress Sicherheitslücke beheben.

WordPress REST API Rate Limiting und Sicherheitshärtung für Headless-Setups

Rate Limiting verhindert, dass die REST API durch Brute-Force-Angriffe oder fehlerhafte Clients überlastet wird. Das ist besonders bei öffentlich zugänglichen Headless-Setups wichtig.

KI-generiertes Bild

Rate Limiting einrichten:

Nginx: Mit limit_req_zone und limit_req Direktiven:

limit_req_zone $binary_remote_addr zone=wp_api:10m rate=30r/m;
location /wp-json/ {
    limit_req zone=wp_api burst=10 nodelay;
}

Cloudflare: Rate Limiting Rules für /wp-json/* konfigurieren (z.B. max. 100 Requests pro Minute pro IP).
WordPress-Plugin: WP REST API Cache oder REST API Toolbox bieten einfache Rate-Limiting-Optionen.

Härtungs-Checkliste für 2026:

✅ WordPress auf mindestens 6.8.6, 6.9.5 oder 7.0.2 aktualisieren [4][6]
✅ Batch-Route (/wp-json/batch/v1) überwachen oder einschränken [6][9]
✅ Benutzer-Endpunkte für anonyme Requests deaktivieren
✅ HTTPS erzwingen (kein HTTP für API-Calls)
✅ Application Passwords mit minimalen Rechten vergeben
✅ WAF-Logs regelmäßig auf ungewöhnliche /wp-json/-Zugriffe prüfen
✅ CDN-Cache für POST/PUT/DELETE-Requests deaktivieren

Wer nach einem Update plötzlich REST-API-Fehler bekommt, sollte auch einen Blick auf WordPress Fehler 500 nach PHP-Update werfen, da PHP-Versionsänderungen manchmal REST-Callbacks brechen.

FAQ: WordPress REST API Fehler beheben

Was ist der Unterschied zwischen 401 und 403 bei der WordPress REST API? 401 bedeutet, dass keine Authentifizierung vorhanden ist (kein Token, kein Cookie). 403 bedeutet, dass eine Authentifizierung vorhanden ist, aber die Berechtigung fehlt, oder dass eine Firewall/WAF den Zugriff blockiert [8][10].

Warum funktioniert /wp-json/ auf meiner Staging-Umgebung nicht? Staging-Umgebungen haben oft einen HTTP-Auth-Schutz (.htpasswd), der alle Requests blockiert, bevor sie WordPress erreichen. Den HTTP-Auth-Header in allen API-Calls mitschicken oder die Staging-IP in der Firewall freigeben.

Wie prüfe ich, ob die REST API aktiv ist? curl https://deine-domain.tld/wp-json/ aufrufen. Eine JSON-Antwort mit "name" und "url" bestätigt, dass die API läuft. Ein 404 oder leere Antwort zeigt ein Konfigurationsproblem [5].

Kann ich die REST API für bestimmte IPs sperren? Ja, über Nginx, Apache oder Cloudflare. Für Headless-Setups mit bekannten Frontend-Server-IPs ist eine IP-Whitelist für Schreib-Endpunkte eine gute Sicherheitsmaßnahme.

Warum gibt /wp-json/wp/v2/users Benutzernamen preis? Das ist WordPress-Standardverhalten. Den Endpunkt für anonyme Requests deaktivieren (Code-Beispiel oben) oder ein Plugin wie Disable REST API verwenden, um gezielt Endpunkte zu sperren [7].

Was tun, wenn ein Security-Plugin die REST API blockiert und ich keinen Admin-Zugriff mehr habe? Per FTP oder Dateimanager das Plugin im Ordner /wp-content/plugins/ umbenennen (z.B. wordfence_disabled). Das deaktiviert das Plugin ohne Admin-Zugriff. Danach die Konfiguration anpassen. Mehr dazu im Artikel WordPress Admin nicht erreichbar.

Wie lange sind WordPress Nonces gültig? Standardmäßig 12 bis 24 Stunden. Für Long-Running-SPAs die Nonce periodisch über einen eigenen Endpoint erneuern oder auf JWT umsteigen.

Sind Application Passwords sicher für Headless-Setups? Ja, für Server-zu-Server-Kommunikation über HTTPS. Niemals im Browser-Frontend verwenden, da das Passwort im JavaScript-Code sichtbar wäre [7][10].

Was bedeutet rest_no_route? Die angeforderte Route existiert nicht in WordPress. Häufige Ursachen: Plugin deaktiviert, das die Route registriert hat, oder Tippfehler in der URL. Alle verfügbaren Routen mit curl https://deine-domain.tld/wp-json/ auflisten.

Wie debugge ich REST API-Fehler in der Produktion ohne WP_DEBUG? Den WordPress Error Log aktivieren (define('WP_DEBUG_LOG', true) in wp-config.php) und /wp-content/debug.log prüfen. Alternativ Anfragen mit curl -v ausführen und den vollständigen Response-Header analysieren.

Fazit: REST API Fehler systematisch beheben

WordPress REST API Fehler beheben bei 404, 403 und Authentifizierungsproblemen in Headless-Setups klingt komplex, folgt aber einem klaren Muster: Zuerst die Infrastruktur prüfen (Permalinks, .htaccess, Nginx), dann Security-Plugins und WAF-Regeln, dann die Authentifizierung.

Konkrete nächste Schritte:

Permalinks zurücksetzen (30 Sekunden, löst 60% der 404-Fehler).
curl -I-Test direkt auf dem Server ausführen und mit lokalem Ergebnis vergleichen.
Security-Plugin-Logs auf blockierte /wp-json/-Requests prüfen.
CORS-Filter in der functions.php für die Frontend-Domain einrichten.
WordPress sofort updaten auf mindestens 6.8.6, 6.9.5 oder 7.0.2 wegen kritischer REST-API-Lücken [4][6].
Authentifizierungsmethode nach Anwendungsfall wählen: JWT für Browser-Frontends, Application Passwords für Server-zu-Server.

Wenn die Fehler trotz dieser Schritte bestehen bleiben oder die Ursache unklar ist, lohnt sich professionelle Hilfe. Kay Jaeger und das Team von WP-Repair haben über 800 WordPress-Seiten mit einer Erfolgsquote von 98,2% gerettet, inklusive komplexer Headless- und API-Probleme. Die Ersteinschätzung ist komplett kostenlos und unverbindlich.

Weitere nützliche Ressourcen: