Vai al contenuto

La sicurezza di una web app interna: le domande da fare allo sviluppatore prima di firmare

Prima di firmare, verifica come lo sviluppatore gestisce accessi, dati e vulnerabilità: se non ti risponde in modo chiaro, il problema è già evidente. Una web app interna è un’applicazione web usata dai dipendenti per operare sui processi aziendali, spesso con dati sensibili al suo interno.

Le domande giuste non riguardano la grafica o le funzioni. Riguardano chi può accedere, come vengono protetti i dati e cosa succede quando qualcosa va storto. Sono le aree dove i problemi restano invisibili finché non esplodono.

Ti spiego quali domande porre, cosa devi pretendere come risposta e quali segnali indicano che stai parlando con la persona sbagliata. Non servono competenze tecniche per capirlo: serve sapere dove guardare.

Perché la sicurezza si decide prima di firmare

La sicurezza di una web app non è una funzione da aggiungere alla fine. È una serie di scelte progettuali che condizionano l’architettura fin dal primo giorno. Rifarle dopo costa molto più che pensarle prima.

Quando firmi un contratto senza chiarire questi punti, accetti implicitamente le scelte dello sviluppatore. Se quelle scelte sono deboli, te ne accorgi quando è tardi: un accesso non autorizzato, dati esposti, un blocco operativo. Il contratto è il momento in cui hai potere negoziale. Dopo, molto meno.

Quali domande devo fare sullo sviluppatore prima di firmare?

Chiedi come gestisce autenticazione, protezione dei dati, backup e aggiornamenti: se risponde in modo vago, non è pronto. Queste quattro aree coprono la maggior parte degli incidenti reali su una web app interna.

L’autenticazione è il processo con cui l’app verifica l’identità di chi accede. L’autorizzazione stabilisce cosa ogni utente può fare una volta entrato. Sono cose diverse e uno sviluppatore serio le distingue senza esitare.

Le domande che ti conviene mettere sul tavolo:

  • Come gestisci l’autenticazione? Deve prevedere password robuste e, dove i dati lo richiedono, un secondo fattore di verifica.
  • Chi può vedere cosa? Ogni ruolo aziendale deve accedere solo ai dati che gli servono, non a tutto il database.
  • Dove risiedono i dati e chi li ospita? Server, provider e localizzazione geografica incidono su sicurezza e conformità.
  • Con che frequenza fai backup e li hai mai testati? Un backup mai ripristinato non è un backup, è una speranza.
  • Come gestisci gli aggiornamenti di sicurezza? Le librerie usate nell’app vanno aggiornate quando emergono vulnerabilità note.

Se su queste domande ricevi risposte precise e argomentate, hai davanti qualcuno che ha già lavorato sulla sicurezza. Se ricevi rassicurazioni generiche del tipo “è tutto sicuro”, manca la sostanza. La sicurezza si spiega nei dettagli, non nelle promesse.

Cosa devo pretendere sul trattamento dei dati?

Pretendi di sapere quali dati raccoglie l’app, dove finiscono e chi vi ha accesso, sia lato tua azienda sia lato fornitore. Con dati sensibili si intendono le informazioni che, se esposte, danneggiano persone o azienda: dati personali, anagrafiche clienti, informazioni economiche.

Chiedi se i dati vengono cifrati. La cifratura è la tecnica che rende i dati illeggibili a chi non possiede la chiave di decodifica. Va applicata sia quando i dati transitano in rete sia quando restano archiviati sul server.

Verifica anche cosa succede alla fine del rapporto. Se un domani cambi fornitore, devi poter esportare i tuoi dati in un formato utilizzabile. La proprietà dei dati resta tua, e questo va scritto nel contratto, non lasciato all’accordo verbale.

Come capisco se lo sviluppatore è affidabile?

Guarda come risponde alle domande scomode, non a quelle facili. Uno sviluppatore affidabile ammette i limiti, spiega i compromessi e ti dice cosa non è incluso nel preventivo. Chi promette sicurezza assoluta sta semplificando qualcosa che non è semplice.

Un altro segnale è la trasparenza sulla manutenzione. Una web app non si consegna e si dimentica: va aggiornata, monitorata, corretta. Se il fornitore non parla di cosa succede dopo il rilascio, ti sta vendendo metà del lavoro.

Nella mia attività sulle Web App parto sempre da qui: chiarire prima cosa serve proteggere e come. Le scelte tecniche vengono dopo, e cambiano a seconda dei dati in gioco e del livello di rischio che l’azienda può accettare.

Dubbi ricorrenti sulla sicurezza di una web app interna

Serve davvero l’autenticazione a due fattori su un’app usata solo internamente?

Dipende dai dati che l’app contiene. Se gestisce informazioni economiche, dati personali o accessi a sistemi critici, il secondo fattore riduce molto il rischio di accessi non autorizzati. Su un’app con dati poco sensibili può essere sproporzionato. La regola è calibrare la protezione sul valore di ciò che proteggi, non applicare tutto ovunque per principio.

Chi è responsabile se la mia web app subisce una violazione?

La responsabilità va definita nel contratto, prima di firmare. In genere lo sviluppatore risponde dei difetti di sicurezza legati a errori nel suo lavoro, mentre l’azienda resta responsabile della gestione degli accessi e dell’uso corretto. Senza clausole chiare, in caso di problema ci si ritrova a discutere di responsabilità quando serve agire in fretta. Chiariscilo per iscritto.

Quanto incide la sicurezza sul costo di una web app?

Incide, ma meno di quanto costa aggiungerla dopo. Progettare accessi, cifratura e backup fin dall’inizio richiede tempo di sviluppo, non tecnologie costose. Il costo maggiore arriva quando la sicurezza va rifatta su un’app già costruita male, perché significa rimettere mano all’architettura. Chiedere sicurezza in fase di preventivo è l’opzione più economica.

Posso far verificare la sicurezza da qualcuno diverso da chi ha sviluppato l’app?

Sì, ed è una scelta sensata su applicazioni che gestiscono dati critici. Un controllo indipendente valuta il lavoro senza il conflitto d’interesse di chi l’ha realizzato. Non serve su ogni progetto, ma su web app che trattano informazioni sensibili offre una garanzia in più. Puoi prevederlo fin dall’inizio, come fase separata del progetto.

Cosa succede se lo sviluppatore sparisce dopo la consegna?

Ti resta un’app che nessuno aggiorna, ed è un rischio concreto. Per questo pretendi accesso al codice sorgente, documentazione tecnica e credenziali di tutti i sistemi coinvolti. Con questi elementi un altro sviluppatore può riprendere il lavoro. Senza, resti bloccato. Metti la consegna di codice e documentazione tra le condizioni contrattuali, non tra gli accordi informali.

Vuoi valutare la sicurezza della tua prossima web app?

Se stai per commissionare una web app interna, il momento giusto per parlare di sicurezza è adesso, prima di firmare qualsiasi cosa.

Lavoro con imprenditori e responsabili che devono decidere a chi affidare un progetto e vogliono capire quali domande porre e quali risposte pretendere. Non serve che tu abbia competenze tecniche: serve sapere dove guardare.

Un primo confronto serve proprio a questo: capire se il tuo progetto è impostato bene o se ci sono punti da chiarire prima di impegnarti. Se vuoi parlarne, scrivimi dalla pagina contatti e vediamo insieme come procedere.

Articoli correlati