La convalida dell'input dei dati è sempre stata una vera lotta interna per me.
Sul punto di aggiungere un vero framework e codice di sicurezza al nostro progetto di riscrittura di applicazioni legacy (che finora mantiene praticamente il codice di sicurezza legacy e la convalida dei dati), mi chiedo ancora quanto dovrei convalidare, dove, ecc.
Durante i miei 5 anni come sviluppatore Java professionale, ho creato e perfezionato le mie regole personali per la convalida dell'input dei dati e le misure di sicurezza. Mentre mi piace migliorare i miei metodi, vorrei che alcuni ascoltassero alcune idee da voi ragazzi. Le regole e le procedure generali vanno bene, e anche quelle specifiche di Java.
Riassumendo, queste sono le mie linee guida (esposte su uno stile di applicazione Web a 3 livelli), con brevi spiegazioni:
Lato client di 1 ° livello (browser): convalida minima, solo regole invariabili (campo email obbligatorio, selezionare un elemento e simili); utilizzo di convalide aggiuntive come "tra 6 e 20 caratteri" meno frequenti, poiché ciò aumenta i lavori di manutenzione sulle modifiche (può essere aggiunto una volta che il codice aziendale è stabile);
Lato server di 1 ° livello (gestione della comunicazione web, "controller"): non ho una regola per questo, ma credo che qui debbano essere gestiti solo gli errori di manipolazione dei dati e di assemblaggio / analisi (il campo del compleanno non è una data valida); l'aggiunta di ulteriori convalide qui rende facilmente un processo davvero noioso;
2 ° livello (livello aziendale): validazione solida, nientemeno; input del formato dei dati, intervalli, valori, controllo dello stato interno se il metodo non può essere chiamato in qualsiasi momento, ruoli / autorizzazioni dell'utente e così via; utilizzare il minor numero possibile di dati di input dell'utente, recuperarli nuovamente dal database se necessario; se consideriamo anche i dati del database recuperati come input, li convaliderei solo se alcuni dati specifici sono noti per essere inaffidabili o sufficientemente corrotti sul DB - la tipizzazione forte fa la maggior parte del lavoro qui, IMHO;
3 ° livello (livello dati / DAL / DAO): non ho mai creduto che fosse necessaria molta convalida, poiché solo il livello aziendale dovrebbe accedere ai dati (la convalida forse in alcuni casi come "param2 non deve essere nulla se param1 è vero"); si noti tuttavia che quando intendo "qui" intendo "codice che accede al database" o "metodi di esecuzione SQL", il database stesso è completamente l'opposto;
il database (modello di dati): deve essere ben pensato, forte e auto-imponente per evitare il più possibile dati errati e corrotti sul DB, con buone chiavi primarie, chiavi esterne, vincoli, tipo / lunghezza / dimensione dei dati / precision e così via: ne tralascio i trigger, poiché hanno una discussione privata.
So che la convalida precoce dei dati è buona e dal punto di vista delle prestazioni, ma la convalida ripetuta dei dati è un processo noioso e ammetto che la stessa convalida dei dati è piuttosto fastidiosa. Ecco perché così tanti programmatori lo saltano o lo fanno a metà strada. Inoltre, ogni convalida duplicata è un possibile bug se non sono sempre sincronizzati. Questi sono i motivi principali per cui preferisco oggigiorno lasciare che la maggior parte delle convalide raggiungano il livello aziendale, a scapito di tempo, larghezza di banda e CPU, eccezioni gestite caso per caso.
Allora, cosa ne pensi di questo? Opinioni opposte? Hai altre procedure? Un riferimento a tale argomento? Qualsiasi contributo è valido.
Nota: se stai pensando al modo Java di fare le cose, la nostra app è basata su Spring MVC e MyBatis (le prestazioni e il modello di database non valido escludono le soluzioni ORM); Ho intenzione di aggiungere Spring Security come nostro fornitore di sicurezza più JSR 303 (Hibernate Validator?)
Grazie!
Modifica: qualche ulteriore chiarimento sul 3 ° livello.