Dal vecchio mysql_ a mysqli e PDO: come si fa davvero il porting nel 2026
Le funzioni mysql_ di PHP sono deprecate dalla 5.5 e rimosse dalla 7.0. Un'applicazione che le contiene ancora gira per forza su una versione di PHP fuori supporto da circa dieci anni: non un problema di stile, ma una falla di sicurezza che cammina. Questo articolo rifà la guida al porting con l'occhio del 2026: cosa fa un convertitore automatico e dove ti lascia scoperto, mysqli o PDO, e perché la posta in gioco non è la deprecazione ma l'SQL injection che il vecchio codice si porta dietro. Continua a leggere
Ultima modifica:
Un agent LLM che può eseguire codice Python, Bash o SQL in autonomia è una backdoor delegata. Permetterlo in produzione senza sandboxing è irresponsabile. La mia architettura usa container effimeri, seccomp filter che bloccano syscall pericolose, capability dropping, network namespace che taglia l'egress. Ti mostro il design, i trade-off performance vs sicurezza, e i test di escape eseguiti per validare l'isolamento. 
I computer quantistici non sono ancora una minaccia operativa, ma i dati cifrati oggi con RSA saranno decifrabili tra 10-15 anni. Per applicazioni che gestiscono dati con vita utile lunga, la migrazione verso algoritmi post-quantistici va pianificata ora. Vi racconto lo stato degli standard NIST e le implicazioni pratiche per PHP. 
La sicurezza come fase finale prima del rilascio è un fallimento annunciato. Ho aiutato un'azienda software con 12 sviluppatori a integrare sicurezza nel ciclo di sviluppo: security gate automatici in CI, revisione delle dipendenze ad ogni PR, threat modeling trimestrale. La velocità di sviluppo non è calata. 
Alle 2 di notte, un cliente mi chiama: il suo VPS ha comportamenti anomali. Nei successivi 30 minuti, ho fatto un elenco di azioni in ordine preciso. Quell'ordine è importante: sbagliarlo significa perdere prove forensi o dare tempo all'attaccante. Vi scrivo il runbook che tengo sempre pronto. 
La vecchia ricetta della "classe di sicurezza" che ripulisce GET e POST all'ingresso non protegge più nulla: è un anti-pattern che dà falsa sicurezza. La doctrine corretta nel 2026 è netta: si valida l'input al confine con una logica di allowlist e si escapa l'output in base al contesto in cui finisce. Vediamo come si fa davvero, con filter_var, prepared statement, htmlspecialchars e una Content Security Policy. 
L'investimento in firewall e antivirus non serve a nulla se il dipendente clicca sul link di phishing. Ho aiutato un'azienda con 45 dipendenti a costruire una cultura della sicurezza partendo dalla formazione pratica, dalle simulazioni di phishing e da procedure semplici che la gente segue davvero. 
Una finanziaria di medie dimensioni mi ha chiesto di revisionare la sicurezza di un'applicazione di prestiti ancora in sviluppo. In due ore di threat modeling con STRIDE abbiamo identificato 14 rischi significativi - cinque dei quali avrebbero richiesto settimane di refactoring se scoperti dopo il lancio. 
Dopo la backdoor xz-utils e il compromise di tj-actions del 2025, ho auditato le dipendenze Composer di 12 clienti PHP: 3 avevano pacchetti con nomi sospetti, nessuno aveva allow-plugins configurato, zero SBOM. Il playbook che ho implementato: pinning, audit in CI, blocco script e SBOM CycloneDX. 
Un gestionale Laravel con APP_DEBUG=true in produzione, dipendenze con CVE critiche, nessuna MFA e zero header di sicurezza. In 14 giorni si porta da "rischio latente" a NIS2-ready operativo, con evidenze documentali per ogni intervento. La checklist che uso per ogni sprint di hardening su applicazioni PHP, con i suoi limiti dichiarati.