Proteggere form e applicazioni web: validazione server-side, XSS e CSRF

Considerare ogni input come non affidabile

Controlli HTML e JavaScript migliorano l’esperienza, ma possono essere aggirati. OWASP raccomanda validazione server-side prima che i dati siano elaborati. Campi con opzioni finite devono corrispondere esattamente a valori ammessi; testo libero richiede limiti di lunghezza, codifica, formato e regole coerenti con l’uso previsto.

La validazione non consiste nel rimuovere caratteri sospetti da qualsiasi campo. Email, nomi, descrizioni, identificatori e file hanno modelli diversi. Preferire allowlist per valori strutturati, rifiutare richieste ambigue e registrare manomissioni significative senza conservare segreti o contenuti sensibili oltre il necessario.

• Schema e tipo verificati sul server
• Limiti di dimensione per campi e richiesta
• Valori enumerati confrontati con allowlist
• Normalizzazione definita prima della verifica
• Messaggi di errore utili senza dettagli interni

Prevenire XSS nel punto in cui il dato viene usato

La difesa principale contro XSS è l’output encoding contestuale: HTML, attributi, URL, CSS e JavaScript hanno regole differenti. I framework moderni effettuano escaping in molti casi, ma funzioni che inseriscono HTML grezzo, template personalizzati e integrazioni possono oltrepassare queste protezioni.

Se gli utenti devono inserire markup, l’encoding ne impedirebbe la resa e serve una libreria di sanitizzazione mantenuta e configurata. Alcuni contesti restano pericolosi anche con encoding e vanno evitati, come event handler inline, eval e costruzione dinamica di codice. CSP riduce l’impatto, ma non sostituisce queste difese.

• API sicure come textContent per testo non fidato
• Encoding scelto per il contesto di output
• Sanitizzazione solo quando l’HTML è una funzione richiesta
• Nessun dato utente in codice o event handler
• CSP come difesa aggiuntiva e monitorata

Proteggere le azioni autenticate da CSRF

CSRF sfrutta il browser di un utente autenticato per inviare una richiesta non voluta. Le applicazioni con sessioni basate su cookie usano normalmente token anti-CSRF verificati dal server, oppure pattern adeguati al framework e all’architettura. Le operazioni che modificano lo stato non devono essere esposte tramite GET.

SameSite riduce alcuni invii cross-site, ma OWASP lo considera difesa in profondità e ne documenta i limiti. Cookie di sessione richiedono anche Secure e HttpOnly quando applicabili, scope ristretto e gestione corretta della durata. Origin o Referer possono offrire un controllo ulteriore sulle richieste sensibili.

• Token imprevedibile associato alla sessione o alla richiesta
• Verifica server-side prima dell’azione
• Nessuna modifica di stato tramite GET
• Cookie Secure, HttpOnly e SameSite espliciti
• Nuova autenticazione o conferma per operazioni critiche

Gestire abuso, upload e osservabilità

Honeypot e CAPTCHA possono ridurre automazione indesiderata ma non correggono vulnerabilità. Rate limit per identità, origine e azione, code di invio e protezioni contro replay devono essere proporzionati. Per gli upload servono estensione e tipo ammessi, verifica del contenuto, nome generato dal server, storage separato e limiti di dimensione.

Log e metriche devono distinguere errori normali, validazioni fallite, token CSRF non validi, picchi e tentativi ripetuti. Gli alert devono avere soglie e responsabili; i log non devono contenere password, token, dati completi dei form o allegati. Test applicativi e review dopo ogni modifica mantengono le difese efficaci.

Domande frequenti