DRY vs Security

Quando si parla di siti web e security é facile rischiare di essere superficiali o farsi prendere dal panico. A me almeno é capitato. La superficialità ci porta ad esempio a pensare che i tool o i framework ci mettano al riparo dai problemi; il panico ci porta all' overengineering. Il risultato é comunque negativo.
Per rispondere coerentemente é necessario coltivare comunque la propria conoscenza; questo non rende il nostro software sicuro in assoluto, beato chi ci riesce, ma ci permette di guardare al problema obiettivamente identificando strategie e principi che minimizzino le attack surface.
L'anno scorso mi é stato consigliato un libro illuminante in tal senso (Ajax Security). Consiglio a chi ha qualche dubbio di dare una occhiata a questo testo, scoprirà come le paure sono fondate, ma anche che un approccio sistematico all'argomento é fondamentale per ottenere buoni risultati.

Programmare orientati alla sicurezza può portare però a violare altri principi di buona programmazione, un esempio che ho vissuto riguarda il DRY. Il principio DRY é in contrasto con un approccio tipo defence in depth (DID). Sequendo questo principio ad esempio la sicurezza di ogni layer non può e non deve essere mai delegata ad altri (someone else's problem). La ridondanza, e la duplicazione dei controlli sono quindi un effetto voluto usando un approccio DID. Nella mia esperienza ho adottato un principio importante "Validate Early Validate Often" (VEVO). Ogni layer all'interno del sistema é responsabile della validazione dei parametri che riceve, secondo le sue conoscenze e i suoi scopi. Ovviamente questa non é una risposta ai problemi di sicurezza ma un approccio alla defence in depth.

Usando un approccio VEVO e costringendo i membri del team a identificare percorsi diversi alla validazione dei dati, mi sono però scontrato con una certa resistenza dovuta alla duplicazione di logica di validazione, in pratica c'era che si opponeva all'approccio dando come giustificazione il mancato rispetto del principio DRY. Eppure anche quando si parla del principio DRY ( vale anche per Separation of Concers e Once And Only Once), occorre valutare attentamente se esistono dei requisiti in contrasto; a mio parere se la sicurezza é un requisito é possibile che si debbano sacrificare altri principi in suo onore.