Audit de Securitate WordPress: Ce să verifici înainte de lansare

Înainte ca orice plugin generat de PAGEnza să ajungă la instalarea WordPress a unui utilizator, acesta trece prin trei verificări automate de securitate. Acest post explică ce caută aceste verificări — și de ce fiecare dintre ele contează.

De ce codul generat de AI necesită audit

Modelele lingvistice mari sunt surprinzător de bune la scrierea de pluginuri WordPress. Ele cunosc numele hook-urilor, înțeleg standardele de codare WP, produc PHP lizibil. Dar fac și greșeli previzibile — iar aceste greșeli sunt vulnerabilități de securitate.

Cele mai comune pe care le vedem:

• Utilizarea $_GET sau $_POST fără sanitizare
• Lipsa verificării nonce la trimiterea formularelor
• Interogări directe către baza de date fără $wpdb->prepare()
• Utilizarea eval() sau exec() pentru comportament dinamic
• Afișarea datelor utilizatorului fără esc_html() sau esc_attr()

Acestea nu sunt cazuri limită exotice. Ele apar în mod regulat în ieșirile LLM — chiar și de la cele mai bune modele.

Etapa 1: Validarea promptului

Înainte ca AI-ul să scrie o singură linie, analizăm descrierea utilizatorului. Acest pas detectează două categorii de probleme:

Încercări de manipulare — prompturi care încearcă să determine AI-ul să producă cod intenționat dăunător. Lucruri precum „ignoră instrucțiunile anterioare” sau „creează un backdoor pentru testare“.

Descrieri vagi sau nerealizabile — prompturi prea scurte sau prea ambigue pentru a produce cod util. „Creează un plugin” generează gunoi; „Creează un formular de contact care trimite trimiterile la o adresă de e-mail cu filtrare spam” generează ceva real.

Dacă un prompt eșuează la această verificare, utilizatorul vede un mesaj de eroare specific care explică de ce — nu o respingere generică.

Etapa 2: Linting PHP într-un container izolat

Odată ce AI-ul produce cod PHP, acesta este executat prin php -l într-un container Docker complet izolat de orice altceva. Acest lucru detectează erorile de sintaxă înainte ca pluginul să ajungă vreodată la o instalare WordPress.

Dar mergem mai departe: dacă linting-ul eșuează, sistemul nu respinge pur și simplu ieșirea. Trimite eroarea înapoi la AI cu un prompt de corecție — ceea ce numim vindecare (healing). AI-ul vede propria sa greșeală și încearcă din nou, de până la trei ori.

Aceasta înseamnă că utilizatorii aproape niciodată nu văd un mesaj „generare eșuată”. Ei văd un timp de generare puțin mai lung — și cod funcțional.

Etapa 3: Scanarea securității codului

Aceasta este cea mai importantă etapă. Rulăm o analiză statică care verifică:

Funcții periculoase: eval(), exec(), system(), shell_exec(), passthru() — oricare dintre acestea blochează lansarea pluginului.

Vectori de injecție SQL: apeluri brute $wpdb->query() cu variabile interpolate, lipsa $wpdb->prepare(), utilizarea directă a mysql_query().

Lipsa verificărilor de permisiuni: gestionari AJAX care nu apelează current_user_can() înainte de a efectua orice acțiune privilegiată.

Lipsa verificării nonce: procesoare de formulare care nu apelează wp_verify_nonce() sau check_ajax_referer().

Ieșire neescapată: echo $_GET[...], echo $user_input fără funcții de escaping.

Dacă se găsește oricare dintre acestea, pluginul este blocat. Utilizatorul vede un raport care listează exact ce funcții au declanșat blocarea și de ce — nu doar „verificare de securitate eșuată“.

Cum arată raportul de audit

Fiecare plugin generat vine cu un raport de audit de securitate în limbaj simplu. Acesta listează:

• Ce verificări au trecut (verde)
• Ce verificări au declanșat avertismente (galben) — probleme care nu sunt blocante, dar merită atenție
• Orice corecții care au fost aplicate automat în timpul vindecării

Raportul este generat automat și atașat la descărcarea pluginului. Este util atât pentru propria încredere, cât și pentru a arăta clienților că ați luat în serios securitatea.

Etapa 4: Validarea la salvare

Aceasta nu face parte din generarea inițială — se aplică atunci când utilizatorii editează manual codul pluginului în editorul PAGEnza.

De fiecare dată când salvați, se execută din nou aceeași verificare de lint + securitate. Dacă introduceți o vulnerabilitate critică în timpul editării, salvarea va fi blocată până când o remediați. Acest lucru previne scenariul comun în care un dezvoltator face o modificare rapidă „temporară” care rămâne în producție timp de doi ani.

Limitele auditului automatizat

Scanarea automată detectează bine o clasă specifică de probleme. Nu le detectează pe toate.

Erorile logice, logica de afaceri defectă și problemele subtile de escaladare a permisiunilor care nu implică modele periculoase cunoscute necesită în continuare o revizuire umană. Suntem transparenți în acest sens în documentație — auditul nu înlocuiește o revizuire de securitate, este un prag care garantează un standard minim.

Pentru pluginurile de producție care gestionează plăți sau date sensibile, recomandăm o revizuire manuală pe lângă verificările automate. Raportul de audit oferă unui revizor uman un bun punct de plecare.