Ma per quanto possano essere buoni gli strumenti automatizzati, non sono una panacea, afferma Nickerson. L'esperto utilizza una combinazione di test di penetrazione e di attività manuali per mostrare agli utenti come è facile usare tecniche di social engineering e sfruttare le vulnerabilità di rete per conquistare l'accesso a grandi quantità di dati.

Per esempio, afferma di aver illustrato a un rivenditore di auto di lusso come combinando alcune informazioni tratte da un database di phising indirizzato ai suoi clienti e alcune lacune nell'infrastruttura di back-end, sia stato possibile prelevare contante dai conti correnti bancari dei clienti.

Brad Johnson, vice president della società di consulenza SystemExperts nel Massachuttes, concorda sul fatto che i team IT dovrebbero aspettarsi che le squadre per test di penetrazione utilizzino strumenti sia manuali che automatici per valutare il proprio ambiente. "Con gli strumenti automatici, è possibile sapere se qualcuno ha uno scanner attivo contro il tuo firewall.
Ma i server web rappresentano la sfida più grande". Johnson fa notare che ci sono una miriade di luoghi in cui i dati in fase di elaborazione attraverso una applicazione web possono essere danneggiati, anche a livello di browser, tra il client e il server, il server front-end, il server back-end e durante l'archiviazione. Raramente le organizzazioni provano la sicurezza dei dati in ciascuno di questi punti prima che l'applicazione sia messa in campo, dice Johnson.

Per esempio, Johnson ha fatto un test di penetrazione su una piccola istituzione bancaria e ha scoperto che essi includono la user ID come parte della URL del conto bancario URL. A un eventuale hacker basterebbe solo modificare la URL per accedere a un altro conto bancario. Purtroppo, questa situazione non è univoca, egli spiega. "Oltre il 50% delle applicazioni web in produzione che testiamo possono effettuare azioni incrociate fra gli account, come ad esempio il login come utente A usando i dati riservati per l'utente B, o l'esecuzione di funzioni che solo l'utente B è autorizzato a fare. Si tratta di solo di un cattivo controllo dell'accesso", egli spiega.

Tuttavia, evidenzia anche che l'IT dovrebbe evitare di puntare il dito contro chi scrive codice web e piuttosto cercare di inserirsi nel processo di sviluppo per assicurarsi che le applicazioni siano sviluppate in modo sicuro