Audit di sicurezza WordPress: Cosa controllare prima di andare online

Prima che qualsiasi plugin generato da PAGEnza raggiunga l'installazione WordPress di un utente, supera tre controlli di sicurezza automatizzati. Questo post spiega cosa cercano questi controlli e perché ognuno di essi è importante.

Perché il codice generato dall'IA necessita di un audit

I grandi modelli linguistici sono sorprendentemente bravi a scrivere plugin WordPress. Conoscono i nomi degli hook, comprendono gli standard di codifica WP, producono PHP leggibile. Ma commettono anche errori prevedibili, e questi errori sono vulnerabilità di sicurezza.

I più comuni che vediamo:

• Utilizzo di $_GET o $_POST senza sanitizzazione
• Mancanza di verifica dei nonce sulle sottomissioni dei moduli
• Query dirette al database senza $wpdb->prepare()
• Utilizzo di eval() o exec() per comportamenti dinamici
• Output di dati utente senza esc_html() o esc_attr()

Questi non sono casi limite esotici. Si presentano regolarmente nell'output dei LLM, anche dai migliori modelli.

Fase 1: Validazione del prompt

Prima che l'IA scriva una sola riga, analizziamo la descrizione dell'utente. Questo passaggio rileva due categorie di problemi:

Tentativi di manipolazione — prompt che cercano di indurre l'IA a produrre codice deliberatamente dannoso. Cose come "ignora le istruzioni precedenti" o "crea una backdoor per i test".

Descrizioni vaghe o impraticabili — prompt troppo brevi o ambigui per produrre codice utile. "Crea un plugin" genera spazzatura; "Crea un modulo di contatto che invia le sottomissioni a un indirizzo email con filtro antispam" genera qualcosa di reale.

Se un prompt non supera questo controllo, l'utente vede un errore specifico che spiega perché, non un rifiuto generico.

Fase 2: Linting PHP in un container isolato

Una volta che l'IA ha prodotto codice PHP, viene eseguito tramite php -l all'interno di un container Docker completamente isolato da tutto il resto. Questo rileva errori di sintassi prima che il plugin raggiunga un'installazione WordPress.

Ma andiamo oltre: se il linting fallisce, il sistema non si limita a rifiutare l'output. Invia l'errore all'IA con un prompt di correzione, quello che chiamiamo guarigione (healing). L'IA vede il proprio errore e ci riprova, fino a tre volte.

Ciò significa che gli utenti quasi mai vedono un messaggio "generazione fallita". Vedono un tempo di generazione leggermente più lungo e codice funzionante.

Fase 3: Scansione di sicurezza del codice

Questa è la fase più importante. Eseguiamo un'analisi statica che controlla:

Funzioni pericolose: eval(), exec(), system(), shell_exec(), passthru() — ognuna di queste blocca il rilascio del plugin.

Vettori di SQL injection: chiamate $wpdb->query() grezze con variabili interpolate, mancanza di $wpdb->prepare(), uso diretto di mysql_query().

Mancanza di controlli dei permessi: handler AJAX che non chiamano current_user_can() prima di eseguire qualsiasi azione privilegiata.

Mancanza di verifica dei nonce: processori di moduli che non chiamano wp_verify_nonce() o check_ajax_referer().

Output non escapato: echo $_GET[...], echo $user_input senza funzioni di escaping.

Se viene riscontrato uno di questi problemi, il plugin viene bloccato. L'utente vede un report che elenca esattamente quali funzioni hanno attivato il blocco e perché, non solo "controllo di sicurezza fallito".

Come appare il report di audit

Ogni plugin generato viene fornito con un report di audit di sicurezza in linguaggio semplice. Elenca:

• Quali controlli sono passati (verde)
• Quali controlli hanno attivato avvisi (ambra) — problemi che non sono bloccanti ma meritano attenzione
• Qualsiasi correzione applicata automaticamente durante la guarigione

Il report viene generato automaticamente e allegato al download del plugin. È utile sia per la tua tranquillità sia per dimostrare ai clienti che hai preso sul serio la sicurezza.

Fase 4: Validazione al momento del salvataggio

Questa non fa parte della generazione iniziale — si applica quando gli utenti modificano manualmente il codice del plugin nell'editor PAGEnza.

Ogni volta che salvi, viene eseguito nuovamente lo stesso lint + scansione di sicurezza. Se introduci una vulnerabilità critica durante la modifica, il salvataggio viene bloccato finché non la correggi. Ciò evita lo scenario comune in cui uno sviluppatore apporta una rapida modifica "temporanea" che rimane in produzione per due anni.

I limiti dell'audit automatizzato

La scansione automatizzata rileva bene una classe specifica di problemi. Non li rileva tutti.

Errori logici, logica di business errata e sottili problemi di escalation dei privilegi che non coinvolgono pattern pericolosi noti richiedono ancora una revisione umana. Siamo trasparenti su questo nella documentazione: l'audit non sostituisce una revisione di sicurezza, è un livello minimo che garantisce uno standard minimo.

Per i plugin di produzione che gestiscono pagamenti o dati sensibili, raccomandiamo una revisione manuale oltre ai controlli automatizzati. Il report di audit fornisce un buon punto di partenza per un revisore umano.