Come verificare la sicurezza del tuo sito web: il lavoro dietro un audit

1. Segui le protezioni lungo un percorso reale

Parti da un’attività che conta per chi usa il sito: creare un account, consultare un ordine, aprire una richiesta di assistenza. Elenca le pagine, i servizi e i dati coinvolti. In questo modo la revisione ha un obiettivo concreto e il lavoro tecnico resta legato a un bisogno reale degli utenti.

Lungo quel percorso lavorano più livelli. La rete rende raggiungibili i servizi previsti. L’applicazione riconosce l’account e applica i permessi. Il browser riceve i contenuti su una connessione cifrata e segue le regole indicate negli header della risposta. Hosting, librerie e servizi esterni sostengono tutto in secondo piano. La OWASP Web Security Testing Guide offre una struttura per esaminare questi livelli uno alla volta. Seguire un percorso aiuta ogni specialista a vedere dove si inserisce il proprio lavoro.

Prima di cominciare, chiarisci il perimetro: quali domini, quali ambienti (produzione, staging) e quali account di prova sono inclusi, e chi ha autorizzato la revisione. Lavora solo su sistemi di cui sei responsabile o per i quali hai un’autorizzazione esplicita.

2. Collega ogni protezione a un risultato utile

Questi risultati aiutano il team a discutere le priorità in modo costruttivo. Un percorso dell’account usato da molti clienti merita attenzione per primo. Un componente condiviso, come il modulo di accesso o il modello di pagina comune, conviene rivederlo presto, perché una buona correzione si propaga a molte pagine. Decidi l’ordine degli interventi in base al percorso che ciascuno protegge e al numero di pagine che ne beneficiano.

3. Account: chi sei e che cosa puoi fare

L’autenticazione stabilisce chi sta usando il servizio, cioè con quale account; l’autorizzazione decide quali azioni e quali dati sono permessi a quell’account. Descrivi le regole in parole semplici: un cliente vede le proprie fatture, un operatore dell’assistenza gestisce le richieste assegnate, un amministratore modifica le impostazioni del team. Questa descrizione diventa direttamente un piano di prova.

Per l’autorizzazione la domanda chiave è se il controllo avviene sul server a ogni richiesta, non solo nell’interfaccia. Una prova semplice, con due account di prova creati da te: apri una fattura con il primo account, poi richiedi la stessa risorsa con il secondo, cambiando l’identificativo nell’indirizzo o nella chiamata API. La risposta attesa è un rifiuto. Nascondere un pulsante non basta: conta che cosa risponde il server.

Rivedi registrazione, accesso, verifica dell’email, recupero della password e uscita come un’unica esperienza. Rendi i moduli compatibili con i gestori di password, usa etichette chiare e, dove l’account lo giustifica, offri l’autenticazione a più fattori con passaggi di attivazione e recupero comprensibili. La guida OWASP all’autenticazione descrive i controlli di base. Per la conservazione delle password, le linee guida dell’ACN (aggiornate a maggio 2026) indicano Argon2id e scrypt come algoritmi di password hashing da preferire, considerano il salt obbligatorio e sconsigliano soluzioni costruite in casa. Fai le prove con account dedicati che rappresentano i ruoli previsti e con dati di esempio facili da riconoscere.

4. Rendi le osservazioni tecniche facili da condividere

Una buona revisione registra che cosa è stato esaminato e che cosa è successo. Per ogni osservazione indica la pagina o il servizio esatto, il valore rilevante della risposta, il comportamento atteso e i passaggi per riprodurla. Nelle note condivise usa dati di esempio e credenziali oscurate. Sviluppatori, assistenza e futuri revisori avranno così un riferimento comune.

Raggruppa le osservazioni per il componente che ne è responsabile: più pagine possono dipendere dalla stessa configurazione della sessione, e più verifiche di rete possono descrivere lo stesso servizio. Un sito pubblico usa di norma la porta 443 per HTTPS, mentre la porta 80, come indica la guida TLS di MDN, dovrebbe servire solo a reindirizzare alla stessa risorsa in HTTPS. Ogni altro servizio raggiungibile da Internet dovrebbe avere uno scopo documentato e un responsabile: così un elenco di dettagli tecnici diventa una mappa comprensibile.

Dai a ogni osservazione il peso giusto. Un header Server o X-Powered-By che rivela software e versione aiuta chi cerca vulnerabilità note: rimuoverlo è buona igiene, ma MDN ricorda che il software si può riconoscere anche in altri modi e che mantenerlo aggiornato è la misura più solida. Accanto ai punti da sistemare conserva anche i controlli superati: la revisione mostrerà le protezioni già presenti.

5. Porta le buone pratiche nello sviluppo quotidiano

Usa componenti di autenticazione consolidati, query parametrizzate per il database e controlli dei permessi lato server. Conserva le credenziali di servizio, come chiavi API e token, in un archivio dedicato ai segreti anziché nel codice o in file di configurazione condivisi, con un responsabile e una procedura di rinnovo. Dai ai cookie di sessione gli attributi adatti al percorso reale: Secure li limita a HTTPS, HttpOnly impedisce agli script della pagina di leggerli (senza cifrarli né bloccarne l’invio), SameSite regola l’invio nelle richieste che partono da altri siti. Il riferimento OWASP sugli header spiega come le regole del browser completano questa base.

Tieni un breve registro dei servizi con scopo, responsabile, versione del software e modalità di aggiornamento. Quando il team aggiunge un fornitore di pagamento o un widget di assistenza, inseriscilo nel registro e ripeti il percorso utente collegato. Aggiornamenti pianificati e una copia della configurazione precedente, pronta per tornare indietro, rendono la manutenzione più facile da coordinare. Poche pratiche applicate in modo coerente nei modelli condivisi diventano uno standard comune per chiunque lavori sul sito.

6. Crea un ritmo di revisione ripetibile

Stabilisci una base di partenza e ripeti gli stessi controlli dopo ogni modifica rilevante. Usa gli stessi indirizzi, gli stessi ruoli e lo stesso percorso, così i confronti restano significativi. Per i permessi, verifica che ogni account di prova ottenga esattamente l’accesso previsto, né più né meno. Per le regole del browser, completa gli stessi moduli e gli stessi ritorni da servizi esterni che usano i visitatori.

1. Registra pagine, ruoli e azioni incluse nella revisione.
2. Esamina le risposte consegnate e annota la protezione osservata.
3. Completa il percorso con account di prova rappresentativi.
4. Annota esito, responsabile e prossima occasione di revisione.

Buone occasioni per una revisione sono i cambi di hosting, le modifiche all’autenticazione, gli aggiornamenti dei modelli condivisi e l’arrivo di nuovi servizi collegati, da affiancare a un ritmo regolare adatto al sito e al team. Un registro datato aiuta un nuovo collega a capire il perché delle scelte. Col tempo diventa una storia pratica di come il sito viene mantenuto e di come sono protette le azioni più importanti per i clienti.

7. Comincia con una piccola revisione

Scegli una pagina pubblica e un’azione dell’account e descrivi le loro protezioni in una breve checklist. Per la parte visibile dall’esterno puoi partire dallo snapshot gratuito di Sitelemetry: otto controlli passivi su un’origine pubblica, senza registrazione. Legge DNS pubblico, record DNS della posta, dati di registrazione del dominio, handshake TLS e risposta HTTP della home page; non invia exploit, non esegue scansioni di porte, non tenta accessi e non genera carico. Non è un penetration test e non entra negli account: le prove su autenticazione e permessi descritte sopra restano un lavoro da fare con i tuoi account di prova. Approfondisci la connessione con la guida a TLS e header di sicurezza e il dominio con la guida a SPF, DKIM e DMARC. Per controllare un solo aspetto, la verifica gratuita degli header di sicurezza valuta otto header principali sulla home page e la verifica SPF e DMARC legge i record di posta di un dominio.