Warum gibt WordPress 'Sie haben keine Berechtigung zum Hochladen' an meine iPhone-App zurück?

Der REST-API-Endpunkt /wp-json/wp/v2/media erfordert, dass der WordPress-Benutzer die Berechtigung upload_files besitzt. Die Rollen Abonnent und Mitarbeiter besitzen sie nicht. Wenn sich Ihre iPhone-App als Benutzer in einer dieser Rollen authentifiziert, gibt jeder Upload-Versuch HTTP 403 mit rest_cannot_create als Fehlercode zurück. Eine Heraufstufung des Benutzers auf Autor (oder eine andere Rolle, die upload_files umfasst) behebt das Problem.

Ich bin Administrator der Website und erhalte trotzdem 'keine Upload-Berechtigung'. Was ist los?

Wenn die Benutzerrolle korrekt ist, ist die nächste wahrscheinliche Ursache ein Sicherheits-Plugin oder eine WAF-Regel, die die REST-API blockiert. Wordfence, iThemes Security, Solid Security und 'Disable REST API'-Plugins haben alle Einstellungen, die Nicht-Browser-REST-Traffic ablehnen können. Cloudflare-WAF-Regeln, die auf /wp-json/ abzielen, haben den gleichen Effekt. Verwenden Sie das Ereignisprotokoll Ihrer Firewall, um die spezifische blockierende Regel zu finden, und nehmen Sie dann nur diese Regel für /wp-json/wp/v2/media aus.

Vergibt das WordPress Application Password dieselbe Rolle wie der Benutzer, zu dem es gehört?

Ja. Application Passwords werden pro Benutzer ausgestellt, und jede mit einem solchen authentifizierte Anfrage läuft als dieser Benutzer mit dessen genauen Berechtigungen. Wenn der zugrunde liegende Benutzer ein Abonnent ist, kann das Application Password nicht hochladen, auch wenn es erfolgreich generiert wurde. Application Passwords haben kein integriertes Ablaufdatum; sie bleiben gültig, bis sie manuell widerrufen werden.

Wie bestätige ich die Berechtigung upload_files vom Terminal aus?

Führen Sie curl mit -u username:application-password aus und senden Sie POST an /wp-json/wp/v2/media mit einem kleinen Testbild. HTTP 201 mit einem JSON-Body, der die neue Medien-ID enthält, bedeutet, dass Uploads funktionieren. HTTP 403 mit dem Code rest_cannot_create bedeutet, dass der Rolle upload_files fehlt. HTTP 401 mit rest_invalid_authentication bedeutet, dass das Application Password falsch oder widerrufen ist. HTTP 403 von einem Nicht-WordPress-Antwortkörper (HTML-Fehlerseite, Cloudflare-Challenge) bedeutet, dass ein vorgelagerter Filter die Anfrage blockiert, bevor WordPress sie sieht.

Sollte ich den Benutzer einfach zum Administrator hochstufen?

Nur als letzter Ausweg und nur für Websites, die Sie vollständig kontrollieren. Das Prinzip der geringsten Rechte besagt, dass Sie dem Benutzer die kleinste Rolle geben sollten, die upload_files gewährt, also Autor. Reservieren Sie Administrator für Konten, die tatsächlich Einstellungen, Plugins oder andere Benutzer verwalten müssen. Eine dedizierte benutzerdefinierte Rolle nur mit upload_files plus den Veröffentlichungsberechtigungen ist für Websites mit mehreren Nutzern noch sicherer.

WordPress-Fehler "Sie haben keine Upload-Berechtigung": So beheben Sie ihn

Kurzfassung: Der Fehler stammt von Ihrem WordPress-Server, nicht von der iPhone-App, dem Browser oder dem Skript, das die Anfrage stellt. Die beiden häufigsten Ursachen sind: (1) der Benutzer hinter Ihrem Application Password besitzt nicht die Berechtigung upload_files, oder (2) ein Sicherheits-Plugin bzw. eine WAF blockiert /wp-json/wp/v2/media, bevor WordPress die Anfrage auswertet. Stufen Sie den Benutzer auf Autor hoch (oder eine andere Rolle, die upload_files enthält), oder nehmen Sie den Medien-Endpunkt von der störenden Firewall-Regel aus, und die Uploads funktionieren sofort.

Überprüft mit WordPress 6.7 am 2. Juni 2026.

Schnelldiagnose: Was Ihnen die Antwort verrät

Bevor Sie etwas ändern, sehen Sie sich die HTTP-Antwort an, die Ihr Client erhält. Jede Kombination aus Statuscode und Fehlertext deutet auf eine andere Ursache hin.

HTTP-Status	Fehlercode	Wahrscheinliche Ursache	Erster Schritt
403	`rest_cannot_create`	Benutzerrolle fehlt `upload_files`	Rolle auf Autor oder höher ändern (siehe Ursache 1)
401	`rest_invalid_authentication`	Application Password falsch oder widerrufen	Application Password neu erzeugen (siehe Ursache 4)
403	HTML-Seite, kein JSON	Sicherheits-Plugin oder WAF hat die Anfrage blockiert	Wordfence / iThemes / Cloudflare Ereignisprotokoll prüfen
503 / Timeout	(kein Body)	WAF oder Rate Limiter hat die Verbindung verworfen	Cloudflare- oder Origin-Firewall-Protokolle prüfen
200	HTML-Seite, kein JSON	WP-REST-API durch Plugin deaktiviert	"Disable REST API" oder vergleichbares Plugin deaktivieren

Wie der Fehler tatsächlich Ihren Client erreicht

Wenn ein Client ein Foto an WordPress hochlädt, sendet er eine POST-Anfrage an /wp-json/wp/v2/media. Die Anfrage enthält einen Authorization-Header mit Ihrem Benutzernamen und einem Application Password – einem Token, das Sie unter Benutzer -> Profil -> Application Passwords erzeugen, eine WordPress-Core-Funktion seit Version 5.6 (offizieller Integrationsleitfaden).

WordPress Core führt dann eine Berechtigungsprüfung durch, bevor die Datei angenommen wird. Die relevante Logik in WP_REST_Attachments_Controller::create_item_permissions_check() lautet:

if ( ! current_user_can( 'upload_files' ) ) {
    return new WP_Error(
        'rest_cannot_create',
        __( 'Sorry, you are not allowed to upload media on this site.' ),
        array( 'status' => rest_authorization_required_code() )
    );
}

Wenn der Benutzer hinter dem Application Password die Berechtigung upload_files nicht besitzt, gibt WordPress HTTP 403 mit einem JSON-Body zurück, der "code": "rest_cannot_create" enthält. Ihr Client empfängt diese Antwort und stellt sie als "Sie haben keine Upload-Berechtigung" dar.

Das bedeutet, dass die Meldung wörtlich gemeint ist: WordPress teilt Ihnen mit, dass der Benutzer nicht hochladen darf. Der nächste Schritt besteht darin herauszufinden, warum. Die vollständige Liste der Rollenberechtigungen ist auf der offiziellen WordPress-Seite zu Rollen und Berechtigungen dokumentiert.

Ursache 1: Der Benutzerrolle fehlt upload_files

Dies ist die häufigste Ursache, die wir in SnapPress-Support-Fällen beobachten. WordPress hat fünf Standardrollen, und nur einige davon können Medien hochladen:

Rolle	Kann Medien hochladen?
Administrator	Ja
Redakteur	Ja
Autor	Ja
Mitarbeiter	Nein
Abonnent	Nein

Wenn Ihr Application Password einem Mitarbeiter oder Abonnenten gehört, schlägt jeder Upload-Versuch mit dem Berechtigungsfehler fehl, auch wenn die Authentifizierung gelingt (das Passwort selbst ist gültig, es verschafft nur nicht genug Zugriff).

So prüfen Sie die Rolle

Melden Sie sich im WordPress-Admin unter https://your-site.example/wp-admin/ an.
Öffnen Sie Benutzer -> Alle Benutzer.
Suchen Sie den Benutzer, dessen Application Password Sie in der Client-App eingetragen haben.
Sehen Sie sich die Spalte Rolle an.

Wenn die Rolle Mitarbeiter, Abonnent oder etwas Benutzerdefiniertes ohne upload_files ist, liegt darin Ihr Problem.

So beheben Sie es (zuerst geringste Rechte)

Die sicherste Lösung ist, den Benutzer auf Autor hochzustufen. Autor ist die minimale Standardrolle, die upload_files umfasst, zusammen mit der Möglichkeit, eigene Beiträge zu erstellen und zu veröffentlichen. Sie kann keine anderen Benutzer, Plugins oder Einstellungen verwalten und ist daher die empfohlene Wahl, wenn nur der Upload-Workflow benötigt wird.

Stufen Sie auf Redakteur hoch, wenn der Benutzer auch Beiträge anderer Autoren bearbeiten und veröffentlichen muss, oder auf Administrator nur dann, wenn der Benutzer tatsächlich die volle Kontrolle über die Website benötigt (zum Beispiel eine Einzelbetreiber-Website, die Sie selbst verwalten). Nach der Änderung der Rolle erzeugen Sie ein neues Application Password für den nun korrekten Benutzer und aktualisieren die Client-App. Das neue Passwort ist empfohlen, aber nicht zwingend erforderlich; es schließt die "veraltete Anmeldedaten"-Hypothese aus.

Was, wenn die Rolle benutzerdefiniert ist?

Wenn Ihre Website ein Rollen-Plugin wie Members oder User Role Editor verwendet, stimmt der Rollenname möglicherweise nicht mit den Standardwerten überein. Öffnen Sie den Rollen-Editor, suchen Sie die dem Benutzer zugewiesene Rolle und bestätigen Sie, dass das Kontrollkästchen upload_files aktiviert ist. Speichern und erneut versuchen. Benutzerdefinierte Rollen sind auch der Ort, an dem sich die meisten Berechtigungsregressionen verbergen; wenn Uploads einst funktionierten und nach einem Plugin-Update stillschweigend nicht mehr funktionieren, sollten Sie hier anfangen. Für Websites mit mehreren Nutzern ist der sauberste Ansatz eine dedizierte benutzerdefinierte Rolle mit upload_files plus den minimalen Veröffentlichungsberechtigungen, die Sie tatsächlich benötigen.

Ursache 2: Ein Sicherheits-Plugin blockiert die REST-API

Wenn Ihre Benutzerrolle bereits upload_files umfasst und Uploads dennoch fehlschlagen, ist der nächste Verdächtige ein Sicherheits-Plugin, das die REST-API-Anfrage abfängt, bevor WordPress Core sie sieht. Häufige Übeltäter:

Wordfence – Firewall-Regeln können auf ungewöhnliche Authorization-Header anschlagen; Rate Limiting kann REST-Traffic drosseln.
iThemes Security / Solid Security – REST-API-Härtungsoptionen können /wp-json/wp/v2/* für alles außer einer eingeloggten Browser-Sitzung blockieren.
Disable REST API – das Plugin, das wörtlich so heißt, blockiert alle REST-Endpunkte standardmäßig; Sie müssen /wp/v2/media auf die Whitelist setzen, damit App-Uploads funktionieren.
SecuPress, Shield Security und ähnliche Plugins haben entsprechende Einstellungen.

Wenn eines davon die Anfrage blockiert, sieht der Client dasselbe Symptom "keine Upload-Berechtigung", weil das Plugin einen 403 zurückgibt, der dem Fehler von WordPress selbst ähnelt. Der Unterschied besteht darin, dass die Prüfung current_user_can() in Core nie ausgeführt wird.

Wordfence im Detail

Zwei Einstellungen sind einen Blick wert. Öffnen Sie Wordfence -> All Options -> Firewall Options:

Brute Force Protection: aggressive Sperreinstellungen können ein Application Password nach einem einzigen Wiederholungsversuch bannen.
Rate Limiting: Schwellenwerte für "If anyone's requests exceed..." gelten auch für REST-Traffic. Eine mobile App, die fehlgeschlagene Uploads wiederholt, kann diese auslösen.

Wenn Sie Wordfence im Verdacht haben, öffnen Sie Wordfence -> Tools -> Live Traffic und lösen Sie einen Upload vom Client aus. Wenn die Anfrage blockiert wird, erscheint der Grund im Log-Eintrag mit der Regel, die ausgelöst hat. Die vollständige Firewall-Referenz finden Sie unter wordfence.com/help/firewall/.

iThemes Security / Solid Security im Detail

Solid Security hat die Position seiner REST-API-Härtung zwischen den Versionen verschoben. In aktuellen Versionen finden Sie die REST-API-Option unter Security -> Settings -> Advanced -> WordPress Tweaks (ältere Versionen platzierten sie unter Tools). Die beiden Zustände, auf die es ankommt, sind:

Default (REST API enabled) – was App-Uploads benötigen.
Restricted – beschränkt REST-Endpunkte auf eingeloggte Browser-Sitzungen; Application-Password-Anfragen können hier fehlschlagen.

Wechseln Sie auf Default, wenn möglich, oder setzen Sie /wp/v2/media explizit auf die Whitelist. Die genaue Bezeichnung kann je nach Version variieren; konsultieren Sie die Solid-Security-Dokumentation für Ihre Version.

So diagnostizieren Sie

Deaktivieren Sie verdächtige Plugins nacheinander und versuchen Sie zwischen jedem den Upload erneut. Das Plugin, dessen Deaktivierung Uploads erfolgreich macht, ist der Übeltäter. Sobald identifiziert, finden Sie die spezifische Einstellung, die die REST-API blockiert, und nehmen Sie /wp-json/wp/v2/media davon aus. Jedes Plugin in der obigen Liste unterstützt in irgendeiner Form eine Ausnahme pro Endpunkt, obwohl die Menüpfade je nach Version variieren.

Ursache 3: Eine WAF blockiert die Anfrage

Wenn Ihre Website hinter einer Web Application Firewall (Cloudflare WAF, Sucuri, AWS WAF, BunkerWeb) liegt, kann die WAF die Upload-Anfrage ablehnen, bevor sie überhaupt Ihren WordPress-Server erreicht. Insbesondere Cloudflare hat WAF-Managed-Rules, die auf große Multipart-POST-Bodies und ungewöhnliche Content-Type-Kombinationen abzielen, die beide bei einem Medien-Upload verwendet werden. Den Regelkatalog finden Sie in der WAF-Dokumentation von Cloudflare.

Die Symptome variieren, aber typischerweise erhalten Sie eines davon:

HTTP 403 mit einer Cloudflare-Fehlerseite im Antwortkörper.
HTTP 503 oder einen Timeout, ohne Fehlerkörper.
HTTP 200 mit einer HTML-Antwort statt JSON.

Cloudflare-spezifische, eng umrissene Lösung

Deaktivieren Sie nicht pauschal Cloudflares Managed Rules. Identifizieren Sie stattdessen die spezifische Regel, die ausgelöst hat:

Öffnen Sie das Cloudflare-Dashboard und gehen Sie zu Security -> Events (ehemals Firewall Events).
Lösen Sie einen fehlschlagenden Upload von Ihrem Client aus.
Filtern Sie Ereignisse nach Host oder nach dem URI /wp-json/wp/v2/media. Die blockierende Regel erscheint mit ihrer Ruleset-ID und Regel-ID.
Erstellen Sie eine benutzerdefinierte Regel unter Security -> WAF -> Custom Rules, die nur diese spezifische Managed Rule für den Upload-Endpunkt überspringt:

(http.request.uri.path eq "/wp-json/wp/v2/media") and (http.request.method eq "POST")

Setzen Sie die Regelaktion auf "Skip", gezielt auf das spezifische Ruleset / die Regel, die Sie identifiziert haben, nicht auf alle Managed Challenges. Platzieren Sie die Regel in der Priorität über allen "Block"-Regeln. So bleibt der Schutz für den Rest von /wp-json/ aktiv, während legitime Medien-Uploads durchgelassen werden.

Ursache 4: Authentifizierungsfehler oder widerrufenes Application Password

Application Passwords haben kein integriertes Ablaufdatum; einmal ausgestellt, bleiben sie gültig, bis sie manuell widerrufen werden. Das Symptom hier ist daher in der Regel HTTP 401 mit rest_invalid_authentication, nicht der 403-Berechtigungsfehler. Aber es lohnt sich zu prüfen, wenn nichts anderes passt:

Öffnen Sie WordPress-Admin -> Benutzer -> Profil -> Application Passwords.
Bestätigen Sie, dass das in der Client-App registrierte Passwort noch aufgeführt ist.
Wenn es entfernt wurde (manuell, durch ein Sicherheits-Plugin oder durch ein Passwortänderungsereignis), erzeugen Sie ein neues und aktualisieren Sie den Client.
Stellen Sie sicher, dass Ihre Website über HTTPS erreichbar ist. WordPress entfernt den Authorization-Header bei einfachem HTTP aus Sicherheitsgründen; eine HTTP/HTTPS-Diskrepanz kann zu sporadischen 401-Fehlern führen.
Stellen Sie sicher, dass kein Sicherheits-Plugin oder benutzerdefinierter Code Application Passwords über den Filter wp_is_application_passwords_available deaktiviert hat.

Einige Sicherheits-Plugins widerrufen Application Passwords bei bestimmten Ereignissen automatisch (Passwortänderungen, Rollenänderungen, verdächtige Aktivität). Wenn Ihre Rolle kürzlich geändert wurde, kann das allein bestehende Passwörter widerrufen haben. Eine Neugenerierung ist eine Lösung in einer Minute.

Die Lösung über die Kommandozeile bestätigen

Nachdem Sie eine Lösung angewendet haben, können Sie überprüfen, ob Uploads funktionieren, ohne die Client-App überhaupt einzubeziehen. Führen Sie von einem beliebigen Rechner mit curl Folgendes aus:

curl -u 'your-username:your-application-password' \
  -X POST \
  -H 'Content-Disposition: attachment; filename=test.jpg' \
  -H 'Content-Type: image/jpeg' \
  --data-binary @test.jpg \
  https://your-site.example/wp-json/wp/v2/media

Ein erfolgreicher Upload gibt HTTP 201 und einen JSON-Body zurück, der id, source_url und media_details des neuen Medienobjekts enthält. Alles andere verweist zurück auf die Diagnose-Tabelle am Anfang dieses Artikels, und der Antwortkörper sagt Ihnen in der Regel, welche Zeile zutrifft.

Wenn Sie curl nicht ausführen können, lässt sich derselbe Test mit Postman oder einem beliebigen HTTP-Client durchführen, der Basic-Authentifizierung und Multipart-Formulardaten unterstützt. Der Endpunkt, die Anmeldedaten und die erwartete Antwort sind identisch.

Warum eine Mobile-App das nicht für Sie lösen kann

Es ist verlockend anzunehmen, dass ein Upload-Bug in der App liegen muss, weil die App der sichtbare Teil der Kette ist. Aber die WordPress-REST-API ist die maßgebliche Instanz dafür, was ein Client (Browser, iOS-App, Zapier, Kommandozeile) tun darf. Die Aufgabe der App ist es, eine wohlgeformte Anfrage mit gültigen Anmeldedaten zu senden und die Antwort darzustellen. Wenn WordPress "keine Upload-Berechtigung" sagt, kann eine Änderung an der App die Antwort nicht ändern. Die Lösung muss auf der WordPress-Seite erfolgen: Rolle, Plugin-Einstellungen, WAF-Regeln oder Application Password.

Das ist so vorgesehen und ist eine Stärke des REST-API-Modells. Dieselben Prüfungen schützen Ihre Website, egal ob jemand eine Telefon-App, einen Desktop-Client oder ein benutzerdefiniertes Skript verwendet.

Zusammenfassende Checkliste

Lesen Sie den HTTP-Statuscode und den Fehlercode aus der tatsächlichen Antwort. Gleichen Sie sie mit der Diagnose-Tabelle oben ab.
Prüfen Sie die WordPress-Benutzerrolle. Sie muss upload_files enthalten (Autor oder höher unter den Standardrollen).
Wenn die Rolle korrekt ist, deaktivieren Sie Sicherheits-Plugins einzeln und versuchen Sie den Upload erneut.
Wenn kein Plugin die Ursache ist, prüfen Sie das Ereignisprotokoll Ihrer WAF; fügen Sie eine eng umrissene Regelausnahme für /wp-json/wp/v2/media nur für die spezifisch auslösende Regel hinzu.
Bestätigen Sie, dass das Application Password noch im Benutzerprofil aufgeführt ist und Ihre Website auf HTTPS läuft; bei Bedarf neu erzeugen.
Verifizieren Sie End-to-End mit curl, bevor Sie zur Client-App zurückkehren.

Wenn Sie diese Reihenfolge einhalten, lassen sich die meisten "keine Upload-Berechtigung"-Meldungen lösen, die wir von SnapPress-Nutzern erhalten. Die Fehlermeldung tut ihren Job; sie braucht nur den richtigen Kontext, um darauf zu reagieren.

Häufig gestellte Fragen

Warum gibt WordPress 'Sie haben keine Berechtigung zum Hochladen' an meine iPhone-App zurück?: Der REST-API-Endpunkt /wp-json/wp/v2/media erfordert, dass der WordPress-Benutzer die Berechtigung upload_files besitzt. Die Rollen Abonnent und Mitarbeiter besitzen sie nicht. Wenn sich Ihre iPhone-App als Benutzer in einer dieser Rollen authentifiziert, gibt jeder Upload-Versuch HTTP 403 mit rest_cannot_create als Fehlercode zurück. Eine Heraufstufung des Benutzers auf Autor (oder eine andere Rolle, die upload_files umfasst) behebt das Problem.
Ich bin Administrator der Website und erhalte trotzdem 'keine Upload-Berechtigung'. Was ist los?: Wenn die Benutzerrolle korrekt ist, ist die nächste wahrscheinliche Ursache ein Sicherheits-Plugin oder eine WAF-Regel, die die REST-API blockiert. Wordfence, iThemes Security, Solid Security und "Disable REST API"-Plugins haben alle Einstellungen, die Nicht-Browser-REST-Traffic ablehnen können. Cloudflare-WAF-Regeln, die auf /wp-json/ abzielen, haben den gleichen Effekt. Verwenden Sie das Ereignisprotokoll Ihrer Firewall, um die spezifische blockierende Regel zu finden, und nehmen Sie dann nur diese Regel für /wp-json/wp/v2/media aus.
Vergibt das WordPress Application Password dieselbe Rolle wie der Benutzer, zu dem es gehört?: Ja. Application Passwords werden pro Benutzer ausgestellt, und jede mit einem solchen authentifizierte Anfrage läuft als dieser Benutzer mit dessen genauen Berechtigungen. Wenn der zugrunde liegende Benutzer ein Abonnent ist, kann das Application Password nicht hochladen, auch wenn es erfolgreich generiert wurde. Application Passwords haben kein integriertes Ablaufdatum; sie bleiben gültig, bis sie manuell widerrufen werden.
Wie bestätige ich die Berechtigung upload_files vom Terminal aus?: Führen Sie curl mit -u username:application-password aus und senden Sie POST an /wp-json/wp/v2/media mit einem kleinen Testbild. HTTP 201 mit einem JSON-Body, der die neue Medien-ID enthält, bedeutet, dass Uploads funktionieren. HTTP 403 mit dem Code rest_cannot_create bedeutet, dass der Rolle upload_files fehlt. HTTP 401 mit rest_invalid_authentication bedeutet, dass das Application Password falsch oder widerrufen ist. HTTP 403 von einem Nicht-WordPress-Antwortkörper (HTML-Fehlerseite, Cloudflare-Challenge) bedeutet, dass ein vorgelagerter Filter die Anfrage blockiert, bevor WordPress sie sieht.
Sollte ich den Benutzer einfach zum Administrator hochstufen?: Nur als letzter Ausweg und nur für Websites, die Sie vollständig kontrollieren. Das Prinzip der geringsten Rechte besagt, dass Sie dem Benutzer die kleinste Rolle geben sollten, die upload_files gewährt, also Autor. Reservieren Sie Administrator für Konten, die tatsächlich Einstellungen, Plugins oder andere Benutzer verwalten müssen. Eine dedizierte benutzerdefinierte Rolle nur mit upload_files plus den Veröffentlichungsberechtigungen ist für Websites mit mehreren Nutzern noch sicherer.