Come proteggere un modulo web (spam, injection, GDPR)
Un modulo web protetto male espone a tre rischi distinti: lo spam automatizzato che intasa la casella di posta, le injection di codice che compromettono il database e la mancata conformità al GDPR nella raccolta di dati personali. Questi tre rischi si affrontano con misure diverse e complementari: nessuna sostituisce le altre.
Il vero problema: un modulo è una porta aperta sul server
A differenza di una pagina di contenuto statico, un modulo accetta un input esterno e lo trasmette al server per l'elaborazione (invio di un'email, registrazione in un database). È proprio questa interazione a renderlo un bersaglio privilegiato: ogni campo di inserimento è un potenziale punto di accesso per contenuti malevoli, che si tratti di un semplice messaggio di spam o di un tentativo di attacco più elaborato.
I bot che scansionano il web non prendono di mira siti specifici: testano sistematicamente tutti i moduli che trovano, alla ricerca di una falla sfruttabile. Un modulo di contatto lasciato senza protezione riceve solitamente spam nel giro di pochi giorni, a volte di poche ore, dalla sua messa online.
Proteggersi dallo spam automatizzato
- Aggiungere un campo honeypot: un campo invisibile per un essere umano (nascosto via CSS) ma compilato automaticamente dai bot, che consente di scartare silenziosamente il loro invio senza consumare risorse su un captcha.
- Integrare un captcha (reCAPTCHA, hCaptcha o equivalente) per i moduli più esposti, privilegiando le versioni recenti che non impongono un test visivo sistematico ai visitatori legittimi.
- Limitare la frequenza di invio da uno stesso indirizzo IP, per bloccare gli invii massivi automatizzati.
- Verificare il formato dei campi (email valida, numero di telefono plausibile) prima di accettare l'invio.
- Filtrare link e parole chiave sospette nel contenuto del messaggio, tecnica complementare ma mai sufficiente da sola.
Evitare le injection di codice
Un'injection si verifica quando un aggressore inserisce codice eseguibile in un campo del modulo previsto per del testo semplice, con l'obiettivo di manipolare il database (injection SQL) o di eseguire codice nel browser di altri visitatori (injection XSS). La difesa si basa su due principi non negoziabili:
- Validare e filtrare sempre i dati lato server, mai solo lato browser: una validazione lato browser può essere facilmente aggirata da un aggressore che non utilizza il modulo così come viene mostrato.
- Utilizzare query preparate nel codice che elabora i dati del modulo, una pratica standard che impedisce strutturalmente l'injection SQL, piuttosto che tentare di "ripulire" manualmente ogni campo.
Su un CMS come WordPress, queste protezioni sono generalmente gestite dal nucleo del software e dai plugin per moduli più affidabili, a condizione di mantenerli aggiornati. Un modulo sviluppato su misura senza queste precauzioni resta la configurazione più a rischio.
Rispettare il GDPR sui dati raccolti
Qualsiasi modulo che raccolga dati personali (nome, email, telefono) è soggetto al GDPR, indipendentemente dalle dimensioni del sito. I punti concreti da verificare:
- Il modulo richiede solo i dati strettamente necessari alla sua finalità (un modulo di contatto non ha bisogno della data di nascita).
- Un'indicazione chiara precisa perché i dati vengono raccolti e chi li tratta.
- Un link all'informativa sulla privacy è accessibile dal modulo.
- Il consenso per un uso secondario (ad esempio una newsletter) è distinto e non preselezionato.
- I dati sono conservati per un periodo definito ed eliminati oltre tale termine, salvo obbligo di legge contrario.
Cosa rende un modulo vulnerabile nella pratica
- Assenza totale di validazione lato server, con una fiducia eccessiva riposta nella validazione del browser.
- Un campo per l'allegato di file che accetta qualsiasi formato, permettendo il caricamento di script malevoli travestiti da allegato.
- Messaggi del modulo mostrati in chiaro senza escaping in una pagina di amministrazione, aprendo la porta a un'injection XSS differita.
- Indirizzo email di ricezione esposto in chiaro nel codice sorgente della pagina, il che facilita la raccolta da parte dei bot di spam.
Da ricordare
- Un modulo cumula tre rischi distinti (spam, injection, GDPR) che richiedono ciascuno una risposta specifica.
- L'honeypot e il captcha riducono lo spam automatizzato senza mai eliminarlo completamente.
- La validazione dei dati deve sempre avvenire lato server; la sola validazione lato browser può essere aggirata.
- Le query preparate sono la protezione di riferimento contro le injection SQL, non il filtraggio manuale di ogni campo.
- La conformità al GDPR impone di raccogliere solo i dati necessari, con una finalità chiara e un periodo di conservazione definito.
Domande frequenti
Un captcha basta a proteggere un modulo dallo spam? Riduce fortemente lo spam automatizzato senza eliminarlo del tutto. Combinato con un honeypot e una validazione lato server, copre la maggior parte dei casi per un modulo standard.
Che cos'è un'injection SQL su un modulo? Una tecnica in cui un aggressore inserisce del codice in un campo per manipolare il database. Si evita validando sistematicamente i dati lato server e utilizzando query preparate.
Il GDPR impone un consenso esplicito per ogni modulo? Impone un consenso chiaro e informato, con una finalità precisata. Ciò non significa una casella per ogni campo, ma il visitatore deve sapere perché i suoi dati vengono raccolti.
Bisogna cifrare i dati inviati tramite un modulo? L'HTTPS cifra già il trasporto, il che copre l'essenziale per un modulo standard. Una cifratura aggiuntiva in fase di archiviazione si giustifica soprattutto per dati sensibili.
In sintesi
Proteggere un modulo web richiede di affrontare separatamente lo spam, le injection di codice e la conformità al GDPR, piuttosto che contare su un'unica protezione per coprire tutti e tre gli aspetti. Le basi (honeypot, validazione lato server, raccolta minima di dati) sono accessibili senza una competenza avanzata e sono sufficienti per la maggior parte dei moduli di contatto professionali. La formula sito web in abbonamento di VeryAppi include moduli sicuri e conformi fin dalla messa online. Se desidera approfondire con il Suo team, siamo a disposizione per illustrarLe nel dettaglio queste misure.
Domande frequenti
›Un captcha basta a proteggere un modulo dallo spam?
Un captcha riduce fortemente lo spam automatizzato ma non lo elimina del tutto, soprattutto di fronte a servizi economici di risoluzione manuale. Combinato con un campo honeypot e una validazione lato server, copre la maggior parte dei casi per un modulo di contatto standard.
›Che cos'è un'injection SQL su un modulo?
È una tecnica in cui un aggressore inserisce del codice in un campo del modulo (al posto di una risposta normale) per manipolare il database del sito: estrarre, modificare o eliminare dati. Si evita validando e filtrando sistematicamente i dati lato server, mai solo lato browser.
›Il GDPR impone un consenso esplicito per ogni modulo?
Il GDPR impone un consenso chiaro e informato per qualsiasi raccolta di dati personali, con una finalità precisata. Ciò non significa necessariamente una casella separata per ogni campo, ma il visitatore deve sapere perché i suoi dati vengono raccolti e poter opporsi facilmente.
›Bisogna cifrare i dati inviati tramite un modulo?
L'HTTPS cifra già il trasporto dei dati tra il browser e il server, il che copre l'essenziale per un modulo standard. Una cifratura aggiuntiva in fase di archiviazione si giustifica per dati sensibili (dati sanitari, dati bancari), raramente per un semplice modulo di contatto.