Qualcuno invia il tuo modulo con un indirizzo email non valido. Il modulo lo accetta. L'email di benvenuto rimbalza. Non sentirà mai parlare di te. Un'altra persona invia il modulo senza i campi obbligatori. Il modulo passa lo stesso. Il tuo team si ritrova con dati incompleti. Entrambi i problemi nascono da una validazione assente o sbagliata.
La validazione è il controllo che i dati del modulo siano validi prima di accettarli. Avviene in due punti: nel browser e sul server. Contano entrambi. Questo articolo spiega come funziona la validazione, perché servono tutti e due i livelli e quali sono gli errori più comuni.
Che cos'è la validazione?
La validazione controlla che i dati di un modulo rispettino le tue regole. I campi obbligatori hanno un valore. I campi email contengono una chiocciola (@). I campi telefono contengono solo numeri. I file caricati sono sotto il limite di dimensione.
Senza validazione, i dati sbagliati entrano nel tuo sistema. Il backend va in crash. Il servizio email rifiuta i messaggi. Perdi tempo a ripulire dati sporchi.
La validazione avviene in due punti: lato client (nel browser, prima dell'invio) e lato server (sul tuo server, dopo l'invio). Servono entrambe.
Validazione lato client
Il browser può controllare i dati del modulo prima di inviarli. HTML ha attributi di validazione integrati. Anche JavaScript può validare.
Validazione HTML
<input type="email" required> verifica che il campo abbia un valore e che somigli a un'email. Il browser mostra un messaggio di errore se l'utente prova a inviare un modulo non valido.
Gli attributi di validazione HTML includono required, per imporre che il campo abbia un valore, min/max per i numeri, per tenere i valori in un intervallo, minlength/maxlength, per imporre il numero di caratteri, pattern, per far corrispondere un'espressione regolare, e type, per validare il tipo stesso del campo. Per esempio, type="email" controlla il formato mentre type="number" rifiuta l'input non numerico.
La validazione HTML funziona subito, senza bisogno di JavaScript, e offre buoni messaggi di errore del browser, con tastiere mobili che cambiano in base al tipo di campo. Gli svantaggi: i messaggi di errore del browser sono generici e a volte poco chiari, non puoi personalizzarli senza JavaScript e browser diversi mostrano messaggi diversi.
Validazione JavaScript
Per avere più controllo, valida con JavaScript usando function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } e form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });. La validazione JavaScript ti permette di scrivere regole personalizzate, mostrare messaggi di errore personalizzati e validare i campi mentre l'utente scrive, in tempo reale. Gli svantaggi: richiede JavaScript (non affidabile per la sicurezza), richiede più codice da mantenere e può mostrare errori prima che l'utente finisca di scrivere se validi sull'evento input.
Validazione lato server
Dopo l'invio del modulo, il server controlla di nuovo i dati. È qui che si gioca la vera sicurezza.
Non fidarti mai della validazione lato client. Qualcuno può disattivare JavaScript. Qualcuno può intercettare la richiesta e modificare i dati. Qualcuno può usare curl o uno strumento per inviare dati sbagliati senza passare dal tuo modulo.
La validazione lato server è l'unica protezione che hai. Non è facoltativa.
Quando il server riceve l'invio del modulo, controlla che i campi obbligatori ci siano, valida il formato di email, telefono e URL, controlla che i numeri rientrino negli intervalli previsti, verifica che i file caricati siano del tipo e della dimensione giusti, assicurati che i dati non siano troppo lunghi e sanifica i dati per prevenire gli attacchi injection. Se la validazione fallisce, invia una risposta di errore: il modulo non deve essere elaborato e l'utente deve sapere che cosa non va. La validazione lato server è più lenta perché l'utente deve aspettare una risposta, ma è affidabile e sicura, quindi falla sempre.
Quando usare ciascun tipo di validazione
La validazione lato client serve all'esperienza d'uso. Dice subito all'utente se qualcosa non va. Non deve inviare il modulo per scoprire che un'email non è valida.
La validazione lato server serve all'integrità dei dati e alla sicurezza. Garantisce che i dati sbagliati non entrino mai nel tuo sistema.
Usale entrambe. Lato client per velocità e riscontro. Lato server per protezione e sicurezza.
Errori comuni di validazione
Fare solo la validazione lato client
Qualcuno disattiva JavaScript e la tua validazione sparisce. Qualcuno usa curl per inviare con POST dati sbagliati e la tua validazione non parte mai. Ti ritrovi con spazzatura nel database.
Valida sempre sul server. Il lato client è un extra.
Validare in modo troppo rigido
La tua validazione email è così rigida che le email vere falliscono. La tua validazione del telefono accetta solo il formato statunitense e rifiuta i numeri internazionali. Il campo nome rifiuta trattini, apostrofi e altri caratteri validi.
Prova la validazione con dati reali. Chiedi di provarla a utenti di altri paesi. Rendi le regole il più permissive possibile, pur intercettando i dati sbagliati.
Non mostrare messaggi di errore chiari
"Input non valido." Che cosa non è valido? Quale campo? Che cosa deve fare l'utente?
I messaggi di errore devono essere specifici: "L'email deve avere tra 5 e 254 caratteri." "Il telefono deve avere 10 cifre." "La password deve contenere almeno un numero."
Mostra l'errore accanto al campo che l'ha causato. Non nasconderlo in un elenco riassuntivo in cui l'utente deve cercarlo.
Validare dati sensibili sul client
Non far passare numeri di carta di credito o password dalla validazione lato client. Non mostrarli nella console del browser. Non registrarli nei log.
Valida i dati sensibili solo sul server, tramite HTTPS.
Non validare i file caricati
Qualcuno carica un file da 100 megabyte. Il tuo server esaurisce lo spazio. Qualcuno carica un file eseguibile. Il tuo server si becca un virus.
Valida tipo e dimensione del file sul server. Controlla che il file sia davvero del tipo che dichiara. Non fidarti solo dell'estensione o del tipo MIME.
Validazione in tempo reale o all'invio
La validazione in tempo reale controlla ogni campo mentre l'utente scrive. L'utente vede subito un messaggio di errore se inserisce qualcosa di sbagliato. Può correggerlo subito.
Svantaggio: se mostri gli errori troppo presto, l'utente si frustra. Mostra gli errori solo dopo che l'utente esce dal campo (evento blur), non mentre sta ancora scrivendo.
La validazione all'invio controlla tutto quando il modulo viene inviato. L'utente compila l'intero modulo e poi vede tutti gli errori insieme.
Svantaggio: l'utente deve tornare indietro a correggere gli errori dopo aver già inviato. Questo interrompe il flusso.
Buona pratica: valida al blur (quando l'utente esce da un campo) per avere un riscontro in tempo reale. Valida all'invio come controllo finale. Mostra tutti gli errori insieme se ce ne sono.
Validazione per tipi di campo specifici
Validazione dell'email
La validazione completa di un'email è complessa (l'RFC 5322 è lungo 60 pagine), quindi nella maggior parte dei casi controlla che il valore contenga una chiocciola e un dominio usando const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;. Così intercetti la maggior parte delle email non valide senza essere così rigido da far fallire quelle vere.
Validazione del telefono
Il formato dei numeri di telefono cambia da paese a paese. Il formato statunitense è (123) 456-7890, quello britannico è +44 20 7946 0958 e in Germania si usa +49 30 123456. Accetta il formato internazionale, togli i caratteri non numerici sul server e salva il telefono come stringa invece che come numero, per conservare gli zeri iniziali usati in alcuni paesi.
Validazione della password
Una buona password è lunga (almeno 12 caratteri) e difficile da indovinare. Non richiedere caratteri speciali o un mix di maiuscole e minuscole, perché queste regole frustrano gli utenti e non migliorano la sicurezza. Buoni requisiti per le password sono almeno 12 caratteri e l'esclusione degli schemi comuni (come "123456" o il nome dell'utente). Usa un indicatore di robustezza della password per mostrare all'utente quanto è sicura la sua.
Validazione della data
Controlla che la data sia nel futuro o nel passato, a seconda del caso. Un modulo di iscrizione a un evento deve rifiutare le date passate. Un modulo con la data di nascita deve rifiutare le date future.
Come WEMASY gestisce la validazione dei moduli
I moduli WEMASY includono una validazione lato client integrata (campi obbligatori, formato email e altro) per dare un riscontro immediato. Quando i moduli vengono inviati, i server di WEMASY validano di nuovo tutti i dati prima di elaborarli. Così gli utenti ricevono un riscontro rapido e i tuoi dati sono protetti.
Scopri le funzioni di validazione nel tuo piano WEMASY.