Application Passwords sunt o funcție utilă în WordPress, dar trebuie tratate ca niște chei de acces reale, nu ca simple setări de confort. Ele permit unor aplicații externe — de exemplu un instrument editorial, o integrare de automatizare sau un serviciu de administrare — să se autentifice în WordPress fără să folosească parola principală a contului.
Avantajul este clar: poți revoca accesul unei aplicații fără să schimbi parola utilizatorului. Riscul apare atunci când sunt create prea multe parole, sunt păstrate neglijent sau sunt folosite de conturi cu privilegii prea mari.
Primul lucru important: Application Passwords funcționează împreună cu REST API. Nu există o variantă „sigură” în care să folosești această funcție ca mecanism de acces extern, dar să ignori complet REST API. Obiectivul realist nu este să ascunzi WordPress de orice cerere API, ci să reduci suprafața de expunere: HTTPS obligatoriu, conturi dedicate, privilegii minime, parole revocate când nu mai sunt folosite și monitorizare periodică.
Înainte să creezi o parolă de aplicație, întreabă-te dacă integrarea are într-adevăr nevoie de ea. Dacă aplicația rulează în interiorul site-ului, ca plugin sau temă, autentificarea prin cookie și nonce este de obicei varianta recomandată de WordPress pentru acțiuni din panoul de administrare. Application Passwords sunt mai potrivite pentru aplicații externe care trebuie să comunice cu site-ul prin REST API peste HTTPS.
Nu crea Application Passwords pe contul principal de administrator decât dacă nu ai alternativă. O practică mai sigură este să creezi un utilizator separat pentru fiecare integrare importantă: de exemplu „Integrare CRM”, „Automatizare articole” sau „Raportare analytics”. Acel utilizator trebuie să primească doar rolul necesar. Dacă integrarea doar citește anumite date sau creează schițe, nu ar trebui să aibă acces de administrator. În WordPress, parola de aplicație moștenește capabilitățile utilizatorului pentru care a fost creată.
La creare, folosește nume clare. „API test” sau „plugin” nu te ajută peste trei luni. Un nume bun ar trebui să spună cine folosește accesul și de ce: „Automatizare — creare drafturi blog”, „Aplicație mobilă — editor”, „Backup extern — citire date”. WordPress afișează informații utile precum data creării, ultima utilizare și ultimul IP folosit. Aceste câmpuri sunt importante pentru audit, mai ales când vrei să identifici parole uitate sau acces care nu mai pare legitim.
Păstrarea parolei este la fel de importantă ca generarea ei. WordPress afișează parola generată o singură dată, imediat după creare. Nu o trimite prin email simplu, chat nesecurizat sau capturi de ecran. Pentru echipe mici, folosește un manager de parole cu acces pe roluri. Pentru aplicații sau servere, preferă variabile de mediu sau un sistem dedicat de secret management, nu fișiere text lăsate în directorul proiectului.
Revocarea trebuie să fie o rutină, nu o măsură de panică. Dacă ai dezinstalat o aplicație, ai schimbat furnizorul, a plecat un colaborator sau vezi că o parolă nu a mai fost folosită de mult timp, revoc-o. Revocarea unei Application Password nu afectează parola principală a contului și nu blochează restul site-ului. Este tocmai motivul pentru care acest mecanism este preferabil partajării parolei reale de administrator.
Pentru site-urile unde nu ai nevoie deloc de acces extern prin Application Passwords, poți dezactiva funcția la nivel de cod, printr-un plugin intern sau prin tema copil, folosind filtrele oferite de WordPress. Această decizie trebuie testată înainte pe staging, pentru că poate rupe integrări legitime. Nu confunda însă dezactivarea Application Passwords cu dezactivarea completă a REST API. Multe funcții moderne din WordPress, inclusiv editorul bloc, pot depinde de REST API.
Dacă vrei să reduci expunerea, începe cu măsurile sigure: forțează HTTPS, elimină conturile nefolosite, activează autentificarea în doi pași pentru conturile importante, limitează rolurile, ține WordPress, temele și pluginurile actualizate și verifică periodic lista de Application Passwords din profilurile utilizatorilor. Pentru site-uri administrate profesional, merită adăugate loguri de autentificare și reguli de securitate la nivel de server sau WAF, dar fără blocări agresive care pot strica funcționalități legitime.
Concluzia practică este simplă: Application Passwords nu sunt periculoase prin definiție, dar devin riscante când sunt tratate ca parole temporare fără evidență. Folosește-le doar când ai nevoie de acces extern, leagă fiecare parolă de o aplicație clară, evită conturile de administrator, verifică „last used” și „last IP”, apoi revocă fără ezitare ce nu mai este necesar.
