Was sind Application Passwords in WordPress?

Application Passwords sind 24 Zeichen lange Zugangsdaten, die mit WordPress 5.6 (Dezember 2020) eingeführt wurden. Sie erlauben externen Anwendungen die Authentifizierung an der WordPress REST API und an XML RPC, ohne dass das Hauptpasswort des Benutzers preisgegeben wird. Jedes Application Password ist an genau einen Benutzer und eine benannte Anwendung gebunden, kann einzeln im Benutzerprofil widerrufen werden und wird über HTTPS per HTTP Basic Authentication übertragen. Sie ersetzen das alte unsichere Muster, das WordPress Hauptpasswort in Drittanbieter Apps zu speichern, und sind heute der empfohlene Weg, WordPress mit mobilen Apps, Deployment Skripten, Headless Frontends, Backup Tools und KI Agenten zu verbinden.

Warum hat WordPress Application Passwords eingeführt?

Vor WordPress 5.6 musste jede REST API oder XML RPC Integration mit Schreibzugriff entweder das Hauptpasswort des Kontos nutzen (Basic Auth) oder auf Drittanbieter Plugins wie JWT Auth oder OAuth setzen. Beides hatte Probleme: Das Hauptpasswort gab vollständige Kontrolle inklusive Theme und Plugin Editor, und ein geleaktes Passwort bedeutete eine komplette Kontoübernahme. Application Passwords lösen das durch separate Zugangsdaten pro App, die sich sofort widerrufen lassen, ohne das Benutzerpasswort zu ändern oder andere Integrationen zu brechen.

Wie funktionieren Application Passwords?

Ein eingeloggter Benutzer öffnet Benutzer » Profil im WordPress Admin, scrollt zum Abschnitt "Application Passwords", gibt einen Namen wie "iPhone App" oder "Backup Skript" ein und klickt auf Neues Application Password hinzufügen. WordPress erzeugt ein 24 Zeichen langes Token, das einmalig im Format xxxx xxxx xxxx xxxx xxxx xxxx angezeigt wird (Leerzeichen sind optional und werden beim Absenden ignoriert). Das Token wird gehasht in der Tabelle wp_usermeta unter dem Schlüssel _application_passwords gespeichert und zusammen mit dem Benutzernamen in HTTP Basic Auth verwendet:

curl -u benutzername:xxxxxxxxxxxxxxxxxxxxxxxx \
     https://example.com/wp-json/wp/v2/posts

Oder per JavaScript fetch aus einem Headless Frontend:

const token = btoa('benutzername:xxxxxxxxxxxxxxxxxxxxxxxx');
fetch('https://example.com/wp-json/wp/v2/posts', {
  headers: { 'Authorization': 'Basic ' + token }
});

Typische Einsatzszenarien für Application Passwords

• Mobile Apps wie die offizielle WordPress iOS und Android App.
• Headless Frontends mit Next.js, Astro, SvelteKit oder Nuxt, die Inhalte über /wp-json/wp/v2/ abrufen.
• CI/CD Deployment Skripte, die Beiträge veröffentlichen, Menüs aktualisieren oder Cache Purges auslösen.
• Backup und Migrations Tools wie UpdraftPlus Remote, ManageWP, MainWP.
• KI Content Workflows, in denen Zapier, Make, n8n oder ein eigener GPT Agent Entwürfe in WordPress anlegt.
• WooCommerce Bestandssync aus einem ERP oder PIM System.

Application Password Schritt für Schritt erstellen

1. Melde dich als Benutzer an, in dessen Namen die Integration arbeiten soll. Jedes Application Password erbt Rolle und Rechte seines Benutzers, lege also wenn möglich einen eigenen Benutzer für die Integration an.
2. Gehe zu Benutzer » Profil (eigenes Profil) oder zu Benutzer » Alle Benutzer » Bearbeiten für ein anderes Konto.
3. Scrolle zu Application Passwords.
4. Vergib einen sprechenden Namen, der App und Gerät identifiziert, etwa Zapier Produktion oder Backupserver eu01.
5. Klicke Neues Application Password hinzufügen.
6. Kopiere das 24 Zeichen lange Token sofort. Es wird genau einmal angezeigt und danach nur noch als Hash gespeichert.
7. Trage Token und WordPress Benutzernamen in die externe Anwendung ein.

Application Passwords widerrufen und prüfen

Auf derselben Profilseite zeigt jedes Application Password Erstelldatum und letzten Zugriff an. Mit Widerrufen neben einem Eintrag invalidierst du ein einzelnes Token, mit Alle Application Passwords widerrufen alle auf einmal. Die Sperre wirkt sofort, ohne Cache Invalidierung. Ein Quartalscheck des "Zuletzt verwendet" Datums hilft, vergessene Integrationen aufzuspüren.

Sind Application Passwords sicher?

Ja, über HTTPS. Jedes Token hat rund 144 Bit Entropie (24 Base32 Zeichen), wird mit phpass gehasht gespeichert und nur im HTTP Authorization Header übertragen. Wichtige Risiken:

• HTTPS ist Pflicht. WordPress lehnt Application Passwords über reines HTTP standardmäßig ab, außer WP_ENVIRONMENT_TYPE ist local.
• Serverseitige Offenlegung. Wer wp_usermeta lesen kann, hat nur den Hash. Ein manipuliertes Plugin könnte aber den Rohheader mitloggen.
• Keine Scopes, kein Ablauf. Ein Token erbt alle Rechte des Benutzers und läuft nie aus. Nutze einen dedizierten Benutzer mit minimaler Rolle (Autor statt Administrator).
• Bei einigen Hardening Plugins deaktiviert, z. B. iThemes Security oder Solid Security. Bei Bedarf explizit wieder aktivieren.

Unterschied zu OAuth, JWT oder API Keys

Für die meisten WordPress Integrationen sind Application Passwords der richtige Standard. OAuth 2.0 lohnt sich erst, wenn du Scopes, Refresh Tokens oder Multi Tenant SaaS brauchst.

Application Passwords komplett deaktivieren

In einem eigenen Plugin oder in der functions.php:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Oder gezielt pro Benutzer:

add_filter( 'wp_is_application_passwords_available_for_user', function ( $available, $user ) {
    if ( user_can( $user, 'manage_options' ) ) {
        return false; // für Administratoren deaktivieren
    }
    return $available;
}, 10, 2 );

Was prüft InspectWP?

InspectWP meldet die Verfügbarkeit der WordPress REST API und markiert den Endpoint /wp-json/wp/v2/users, wenn er Benutzerdaten ohne Authentifizierung preisgibt. Application Passwords selbst tauchen nicht im HTML auf und sind daher nicht Teil eines Crawls. Der REST API Status hilft dir aber zu entscheiden, ob Application Passwords aktiv bleiben sollen.