Una web app aziendale custodisce dati sensibili: anagrafiche clienti e fornitori, contratti, dati finanziari, informazioni di produzione, comunicazioni interne. La sicurezza di questi dati non è un requisito opzionale da affrontare a posteriori, ma un elemento fondamentale dell'architettura che deve essere progettato fin dalle prime fasi di sviluppo.
Il principio del Security by Design — introdotto nel GDPR come obbligo per i sistemi che trattano dati personali — stabilisce che la protezione dei dati deve essere integrata nel sistema dalla progettazione, non aggiunta come strato superficiale a sviluppo concluso. Ecco come si traduce concretamente in una web app custom professionale.
Autenticazione: i livelli di protezione dell'accesso
Username e password: il minimo necessario, non sufficiente da solo
Ogni web app richiede autenticazione, ma la sola coppia username/password è vulnerabile agli attacchi di credential stuffing (uso di credenziali rubate da altri siti), brute force e phishing. Le misure di hardening minime includono: policy di password complessa (lunghezza, caratteri speciali, non riutilizzo), rate limiting sul numero di tentativi falliti, lockout temporaneo dopo N tentativi, notifica all'utente di accessi da dispositivi o IP nuovi.
Two-Factor Authentication (2FA/MFA)
Il secondo fattore di autenticazione aggiunge un livello di protezione che rende inutile la sola conoscenza della password. Le implementazioni più comuni per le web app aziendali sono: TOTP tramite app authenticator (Google Authenticator, Microsoft Authenticator) — il codice a 6 cifre cambia ogni 30 secondi; OTP via SMS o email — meno sicuro del TOTP ma più semplice da adottare; magic link via email — link di accesso usa e getta inviato all'email aziendale. Per le web app con dati particolarmente sensibili o accesso da reti esterne, il 2FA dovrebbe essere obbligatorio.
Single Sign-On (SSO)
Per le aziende che già utilizzano Google Workspace o Microsoft 365, l'integrazione SSO permette agli utenti di accedere alla web app con le stesse credenziali aziendali, senza gestire un'ulteriore coppia di credenziali. Questo migliora sia la sicurezza (le politiche di password e 2FA del provider identity si applicano automaticamente) sia l'usabilità, riducendo il rischio di password deboli o condivise.
Autorizzazione: chi può fare cosa
L'autenticazione verifica chi sei; l'autorizzazione definisce cosa puoi fare. Un sistema di controllo degli accessi basato sui ruoli (RBAC - Role-Based Access Control) assegna permessi granulari per ogni funzione della web app:
- Amministratore: accesso completo, gestione utenti, configurazione sistema
- Manager: accesso ai dati del proprio team, ai report, senza accesso alle configurazioni
- Operatore: accesso solo alle funzioni operative quotidiane, senza visibilità su dati sensibili di altri reparti
- Cliente esterno (portale): accesso esclusivo ai propri dati, nessuna visibilità su dati di altri clienti
I permessi vengono verificati lato server per ogni richiesta — non è sufficiente nascondere un pulsante nell'interfaccia se il corrispondente endpoint API non verifica il permesso.
Protezione dei dati: in transito e a riposo
| Livello | Misura | Standard attuale |
|---|---|---|
| Dati in transito | HTTPS obbligatorio su tutte le pagine | TLS 1.3, certificato SSL valido |
| Dati in transito | Header di sicurezza HTTP | HSTS, CSP, X-Frame-Options |
| Dati a riposo | Cifratura database per dati sensibili | AES-256 per colonne critiche |
| Password | Mai memorizzate in chiaro | bcrypt o Argon2 con salt |
| Sessioni | Token sicuri, scadenza configurabile | JWT firmati con refresh token rotation |
| Backup | Backup cifrati, accesso limitato | Off-site, testati periodicamente |
Prevenzione delle vulnerabilità applicative
Le vulnerabilità più comuni nelle web app (OWASP Top 10) vengono mitigate con pratiche di sviluppo specifiche:
- SQL Injection: uso esclusivo di prepared statement e ORM, mai interpolazione diretta di input utente nelle query
- Cross-Site Scripting (XSS): sanitizzazione e encoding di tutti gli output, Content Security Policy header
- CSRF: token CSRF su tutti i form e le azioni con effetti collaterali
- Insecure Direct Object References: verifica dei permessi server-side su ogni risorsa, non solo nell'interfaccia
- Rate Limiting: limite di richieste per endpoint sensibili (login, password reset, API) per prevenire abusi
GDPR e obblighi specifici per le web app
Una web app che tratta dati personali deve rispettare obblighi specifici previsti dal GDPR:
- Registro dei trattamenti: documentazione di quali dati vengono trattati, con quale base giuridica, per quanto tempo
- Log degli accessi: chi ha acceduto a quali dati e quando — fondamentale in caso di data breach
- Diritti dell'interessato: funzioni integrate per l'accesso, la rettifica, la cancellazione e la portabilità dei dati dell'utente
- Data retention automatica: eliminazione o anonimizzazione automatica dei dati al termine del periodo di conservazione previsto
- Notifica data breach: procedure e log per rispettare l'obbligo di notifica entro 72 ore al Garante in caso di violazione
Il team di sviluppo web app di NEO WEB integra queste misure di sicurezza e conformità in ogni progetto, con un approccio Security by Design documentato. Per valutare la sicurezza della tua web app attuale o progettare un nuovo sistema con le giuste protezioni, contatta NEO WEB per una consulenza tecnica.
