Ce permisiuni ar trebui să primească un instrument AI conectat la WordPress

Un instrument AI conectat la WordPress nu ar trebui să primească rolul Administrator doar pentru că integrarea devine mai simplă. Dreptul corect se calculează pornind de la task: ce obiect citește, ce câmp poate modifica, ce tranziție de status execută, cine aprobă și ce operații trebuie să rămână imposibile. Dacă nu putem scrie această listă înainte de conectare, nu suntem încă pregătiți să oferim acces.

Canalul tehnic — plugin, REST API sau WP-CLI — este o decizie separată, explicată în comparația C13-011. Aici construim „permission envelope”: identitatea, credentialul, capabilitățile, limitele pe obiect și câmp, gestionarea secretului, auditul și revocarea care înconjoară fiecare execuție.

Pornește de la task, nu de la rolul disponibil

Scrie taskul ca o propoziție testabilă: „citește titlul și meta pentru postările dintr-un anumit tip”, „aplică un patch aprobat pe ID-ul 123” sau „programează un draft aprobat”. Evită formulări precum „administrează SEO”, fiindcă ascund zeci de operații și nu permit verificarea dreptului minim.

În arhitectura agentului C13-010, modelul propune, iar executorul determinist mută starea. Aceste componente nu au nevoie de aceeași identitate. Procesul care cercetează poate fi read-only; plannerul poate lucra fără acces WordPress; doar executorul primește dreptul îngust necesar schimbării aprobate.

Separă autentificarea, autorizarea, aprobarea și validarea

Autentificarea răspunde „cine face requestul?”. Autorizarea răspunde „poate acea identitate executa această operație pe acest obiect?”. Aprobarea editorială răspunde „a acceptat un responsabil acest change set?”. Validarea răspunde „datele respectă schema și politica?”. Un sistem sigur cere toate cele patru răspunsuri, nu unul singur.

Contractul de obiect, precondiție, patch, readback și rollback rămâne cel din C09-005 despre WordPress ca strat de execuție. Permisiunea deschide doar poarta tehnică; nu dovedește că patchul este corect, aprobat, actual sau sigur pentru publicare.

Rolurile sunt pachete; capabilitățile sunt controalele efective

Documentația WordPress despre Roles and Capabilities arată că rolurile grupează capabilități. „Editor” sau „Administrator” este convenabil pentru oameni, dar prea grosier pentru o integrare automată. Două instalații pot modifica aceleași roluri, iar custom post types pot mapa diferit drepturile.

Construiește o identitate tehnică dedicată și atribuie numai capabilitățile demonstrate de task. Nu reutiliza contul fondatorului, autorului sau operatorului. Identitatea separată oferă atribuire în audit, revocare fără blocarea unei persoane și posibilitatea de a refuza explicit operațiile administrative.

Exportă înainte de rollout inventarul capabilităților efective și păstrează-l ca dovadă de configurare. Repetă verificarea după instalarea unui plugin, schimbarea rolului sau introducerea unui custom post type. Numele rolului poate rămâne identic în interfață, în timp ce drepturile ori maparea lor pe obiecte se modifică.

Folosește un Application Password separat, nu parola principală

Application Passwords sunt credențiale WordPress destinate accesului programatic. Sunt legate de un utilizator, stocate hash-uit, afișate o singură dată și revocabile individual. Astfel, oprirea unei integrări nu cere schimbarea parolei principale și nu întrerupe celelalte instrumente.

Documentația de autentificare REST API le prezintă pentru requesturi externe, prin HTTPS. Creează unul per integrare și mediu: producție, staging și dezvoltare nu împart credentialul. Denumirea trebuie să identifice sistemul și ownerul, fără să conțină secretul.

Un credential separat nu micșorează singur drepturile

Înregistrarea din referința Application Passwords este legată de un user și poate fi listată, inspectată sau ștearsă. Nu este o listă proprie de scope-uri editoriale. După autentificare, WordPress autorizează requestul prin capabilitățile utilizatorului și regulile endpointului.

Prin urmare, zece Application Passwords create pentru același Administrator nu produc zece identități cu blast radius redus. Ele îmbunătățesc izolarea și revocarea credentialelor, dar toate pot ajunge la drepturile contului. Controlul real cere un user dedicat cu capabilități minime și, ideal, o rută îngustă care validează fiecare schimbare.

Verifică permisiunea pe operație și pe obiect

current_user_can() acceptă și meta capabilities legate de un obiect, precum editarea unei anumite postări. WordPress le mapează la capabilitățile primitive ale utilizatorului în context. Aceasta este mai precis decât „utilizatorul este Editor” și poate respecta autorul, tipul de conținut și configurația instalării.

Executorul trebuie să verifice ID-ul exact din change set, nu doar dreptul general de editare. Adaugă precondiții pentru post type, autor, status curent, versiune și câmpuri. Dacă obiectul a devenit public, și-a schimbat ownerul sau nu mai corespunde hashului aprobat, execuția se oprește înainte de write.

O rută custom trebuie să aibă un gard de autorizare

În documentația despre Routes and Endpoints, callbackul operației și permission callbackul au roluri diferite. Primul execută; al doilea decide cine are acces. Păstrează endpointurile mici: o rută care aplică un patch editorial nu trebuie să instaleze extensii sau să ruleze cod arbitrar.

Ghidul Adding Custom Endpoints recomandă verificarea capabilității, nu simpla stare de autentificare. Permission callbackul primește requestul, deci poate lega dreptul de ID și acțiune. Autentificat înseamnă identificat; autorizat înseamnă eligibil pentru mutația exactă.

Allowlist pentru câmpuri și tranziții, nu acces generic la postare

Endpointul Posts poate modifica titlu, conținut, autor, status, slug, featured media, taxonomii și meta expusă. Un agent care trebuie să schimbe doar excerptul nu are nevoie de libertatea de a muta autorul, a seta private sau a înlocui întregul body.

Executorul primește un patch tipizat și respinge orice cheie din afara allowlistului. Separă operațiile: update draft, schedule, publish și delete nu sunt sinonime. Modelul de aprobare din C09-002 trebuie să lege hashul aprobat de aceleași câmpuri care ajung la executor.

Media primește un drept separat și o politică de fișier

Endpointul Media deservește uploadul și actualizarea attachmenturilor. Capabilitatea upload_files poate fi necesară pentru hero-uri sau vizualuri inline, dar nu justifică overwrite arbitrar, ștergere în masă ori acceptarea oricărui format trimis de model.

Validează MIME real, extensie, dimensiuni, greutate, nume, alt text și relația cu change setul. Blochează executabilele și fișierele necerute. Încarcă mai întâi, verifică attachmentul rezultat și abia apoi atașează ID-ul la postarea aprobată. Dacă uploadul reușește iar updateul postării eșuează, marchează media orfană pentru curățare controlată.

Utilizatorii și administrarea nu aparțin credentialului editorial

Endpointul Users poate expune operații sensibile în funcție de context și drepturi. Un executor de conținut nu trebuie să creeze utilizatori, să schimbe roluri, să reseteze identități sau să citească date care nu sunt necesare taskului.

Blochează implicit manage_options, edit_users, promote_users, delete_users, install_plugins, activate_plugins, edit_plugins, edit_themes și orice execuție arbitrară. Administrarea, updateurile și recovery folosesc un canal separat, o identitate diferită, o fereastră temporară și un operator nominalizat. Nu păstra „admin de rezervă” în procesul agentului.

Limitează și suprafața din afara WordPress

Hardening WordPress tratează permisiunile fișierelor, editarea de cod, HTTPS, backupurile și monitorizarea ca straturi distincte. Credentialul editorial nu are nevoie de SSH, FTP, baza de date, panoul de hosting, DNS sau acces la repository.

Dacă un workflow chiar cere WP-CLI ori deploy, creează o identitate separată cu command allowlist, path fix, mediu confirmat și timp limitat. Nu transforma o nevoie rară de mentenanță într-un privilegiu permanent disponibil fiecărui task editorial. Separarea reduce atât probabilitatea erorii, cât și suprafața incidentului.

Revocarea trebuie testată înainte de incident

Referința WP-CLI pentru Application Passwords include creare, listare, actualizare și ștergere. Indiferent de interfață, runbookul trebuie să spună cine revocă, unde este identificat credentialul, ce joburi se opresc și cum confirmăm că un request nou primește refuz.

Testează revocarea într-un mediu sigur și cronometrează timpul până la blocare. Păstrează un canal administrativ separat pentru incident, dar nu îl expune agentului. Un secret „revocabil” doar în teorie, fără owner sau procedură verificată, nu este un control operațional.

Secretul nu intră în prompt, URL, repository sau log

OWASP Secrets Management recomandă acces granular, least privilege, rotație, revocare, expirare unde este posibil și automatizarea ciclului secretelor. Păstrează credentialul într-un secret store sau mecanism echivalent al runtime-ului, nu în instrucțiunile modelului.

Modelul nu are nevoie să vadă secretul pentru a produce un change set. Executorul îl injectează doar la request și îl maschează în erori. Nu îl pune în query string, screenshot, ticket, documentație, fișier de configurare versionat ori output de debug. Separă secretele per integrare, site și mediu pentru revocare precisă.

Nonce-ul WordPress nu înlocuiește autorizarea

Documentația WordPress despre Nonces spune explicit că ele ajută împotriva unor utilizări abuzive, inclusiv CSRF, dar nu trebuie folosite ca autentificare, autorizare sau control al accesului. Au o durată de viață și nu sunt nonce-uri criptografice de unică folosință.

Pentru requesturile same-origin din wp-admin, nonce-ul completează sesiunea și verificarea capabilității. Pentru integrarea externă, folosește metoda de autentificare potrivită și verifică separat permission callbackul. Un request cu nonce valid, dar fără drept pe obiect, trebuie refuzat; la fel unul autentificat care nu respectă schema.

Datele produse de model rămân input neîncrezător

Ghidul general WordPress de securitate pentru API-uri recomandă să nu avem încredere în input, în API-uri terțe sau chiar în datele din bază fără verificare. Un model poate produce accidental HTML nedorit, ID greșit, status invalid sau câmpuri care nu apar în aprobare.

Preferă validarea strictă, iar când aceasta nu este posibilă aplică sanitizarea documentată de WordPress. Schema fixează tipuri, lungimi, enumuri și formate; policy-ul fixează obiectele și tranzițiile. Sanitizarea nu transformă o operație neautorizată într-una permisă.

Auditul păstrează atribuirea, nu secretul

OWASP Logging ajută la separarea evenimentelor utile de datele care nu trebuie înregistrate. Loghează task ID, change ID, identitate tehnică, credential ID sau fingerprint ne-secret, obiect, capabilitate verificată, hashuri before/approved/after, rezultat, durată și motivul refuzului.

Nu loga parola, headerul Authorization, cookie-ul, nonce-ul complet ori body-uri care pot conține secret. Leagă execuția de Execution Bundle-ul C09-004. Astfel poți răspunde cine a cerut, cine a aprobat, ce identitate a executat și ce a rezultat, fără a crea o copie nouă a credentialului.

Acceptanța include teste pozitive, negative și de revocare

Testul pozitiv dovedește că identitatea poate citi obiectul necesar și aplica patchul aprobat. Testele negative încearcă publicare fără aprobare, ștergere, alt autor, alt post type, câmp nepermis, upload invalid, users, settings, plugins, themes și cod. Fiecare trebuie să eșueze predictibil și să lase audit.

Rulează matricea în PoC-ul C13-009, apoi fixează starea inițială prin baseline-ul C10-004. Revocă credentialul și demonstrează că requestul următor este refuzat. Abia după aceste dovezi există un permission envelope, nu doar o listă optimistă de drepturi.

Regula finală: acordă dreptul minim per task, obiect, câmp, status, mediu și interval de timp. Folosește identitate și Application Password dedicate, ține secretul în afara modelului, separă administrarea și testează explicit ce nu poate face integrarea. Un instrument automat este sigur nu când „are acces”, ci când limitele lui pot fi demonstrate și revocate.