Checklist di lancio del sito web: otto controlli di sicurezza prima di andare online

1. La checklist pre-lancio in sintesi

Controlla ogni nome pubblico che servi, di solito il dominio senza prefisso e www, sia su http:// sia su https://. Prima del cambio DNS puoi provare il nuovo server con il nome reale usando curl -sI --resolve example.com:443:203.0.113.10 https://example.com/, sostituendo l’indirizzo IP di esempio con quello del nuovo server.

Le otto righe seguono gli otto controlli passivi dello snapshot gratuito di preparazione al lancio, che esamina un’origine pubblica senza account. I passaggi manuali che seguono vanno oltre ciò che un singolo passaggio su una sola origine può fare: coprono ogni hostname, entrambi gli schemi, le pagine di errore, DKIM e le impostazioni del registrar.

2. Risoluzione DNS: ogni nome punta al nuovo host

Perché conta. Una migrazione parziale è facile da non notare: il dominio senza prefisso è sul nuovo server mentre www è ancora un CNAME verso la vecchia piattaforma. I record dimenticati sono anche un problema di sicurezza. La cheat sheet OWASP sul subdomain takeover spiega come un CNAME che punta a una risorsa cloud eliminata permetta a un altro di appropriarsi del sottodominio, e come un record MX orfano permetta a un attaccante di ricevere la posta del sottodominio e persino di ottenere certificati con la validazione via email.

Come verificare.

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short NS example.com

Ripeti le query su un resolver pubblico (dig @1.1.1.1 …) nel caso la tua rete conservi una risposta in cache, poi passa in rassegna l’esportazione completa della zona dal tuo provider DNS.

Come appare un buon risultato. Ogni nome pubblico risolve verso l’host previsto, i record AAAA esistono solo se l’host serve davvero il sito su IPv6, rispondono almeno due name server (il minimo fissato dalla RFC 1034) e ogni record ha uno scopo e un responsabile noti.

Correzione tipica. Reindirizza o elimina i record obsoleti. Quando dismetti un servizio, segui l’ordine consigliato da OWASP: aggiorna o rimuovi il record DNS, attendi almeno un TTL e solo dopo elimina la risorsa cloud. Prima di un passaggio, abbassa il TTL con un anticipo tale che il vecchio TTL, più lungo, sia scaduto quando fai il cambio, e rialzalo quando la migrazione è stabile.

3. SPF, DMARC e CAA: i record che parlano a nome del tuo dominio

Perché conta. Chiunque può mettere il tuo dominio in un campo From. SPF elenca i server autorizzati a inviare posta per il dominio, DKIM firma i messaggi e DMARC indica ai destinatari che cosa fare quando né SPF né DKIM passano in allineamento con il dominio From visibile. Gmail, Yahoo e Outlook.com richiedono tutti e tre ai mittenti di grandi volumi. CAA indica le autorità di certificazione autorizzate a emettere certificati per i tuoi nomi, e le CA pubbliche devono controllarlo prima dell’emissione.

Come verificare. Interroga il dominio usato negli indirizzi From, di solito il dominio registrato e non www:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

Come appare un buon risultato.

• SPF: esattamente un record v=spf1, entro il limite della RFC 7208 di 10 termini che generano query DNS (gli include annidati contano), che termina con ~all o -all, mai +all.
• DMARC: un record come v=DMARC1; p=none; rua=mailto:dmarc@example.com, in modo che i report arrivino prima di irrigidire la policy. Lo standard attuale, la RFC 9989 (maggio 2026), afferma che i domini i cui utenti potrebbero scrivere in mailing list non dovrebbero pubblicare p=reject; chi lo vuole comunque dovrebbe prima restare almeno un mese a p=none e altrettanto a quarantine, confrontando i report.
• DKIM: ogni servizio che invia per te firma con il tuo dominio. Le chiavi pubbliche si trovano in selector._domainkey.example.com, quindi serve ogni selector per cercarle; compare nel tag s= dell’header DKIM-Signature di un messaggio inviato dal servizio.
• CAA: un record come 0 issue "letsencrypt.org" per ogni CA che usi, compresa quella del tuo CDN. L’assenza di CAA è ammessa, e CAA non impedisce a una CA autorizzata di emettere certificati errati.

Correzione tipica. Unisci i record SPF duplicati, elimina gli include dei servizi dismessi e parti da DMARC con p=none e report. Un hard fail non è automaticamente più sicuro: la RFC 9989 avverte che con -all la posta può essere rifiutata in base al risultato SPF prima che DMARC venga valutato, anche quando una firma DKIM allineata sarebbe passata, e questi rifiuti non compaiono nei report DMARC. I destinatari che non trovano un record DMARC su un sottodominio risalgono l’albero DNS fino alla policy del dominio padre, e una CA usa il record CAA più vicino, al livello del nome per cui emette o sopra, come spiega la pagina CAA di Let’s Encrypt. Un record _dmarc o CAA mancante su www non è quindi una lacuna in sé. La guida alla verifica di SPF e DMARC spiega come leggere e correggere questi record, e la verifica gratuita SPF e DMARC consulta i record SPF, DMARC, MTA-STS e CAA dell’hostname inserito.

4. Certificato TLS: valido, corrispondente e rinnovato da qualcuno

Perché conta. Un certificato scaduto o non corrispondente ferma i visitatori con un avviso del browser, e su un host che usa HSTS non possono nemmeno proseguire. I rinnovi diventano anche più frequenti: secondo il Ballot SC081v3 del CA/Browser Forum, i certificati pubblicamente attendibili emessi dal 15 marzo 2026 valgono al massimo 200 giorni, che scendono a 100 da marzo 2027 e a 47 da marzo 2029. Let’s Encrypt ha smesso di inviare le email di scadenza il 4 giugno 2025.

Come verificare. Per ogni hostname:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

Esegui anche s_client da solo: l’output dovrebbe includere Verify return code: 0 (ok) e mostrare il protocollo negoziato.

Come appare un buon risultato. La catena si verifica con gli intermedi inviati dal server, il certificato copre ogni nome servito, la connessione usa TLS 1.3 o 1.2, il rinnovo è automatico e il runbook indica chi ne è responsabile. Esiste un avviso di scadenza che non dipende dall’autorità di certificazione.

Correzione tipica. Automatizza il rinnovo con ACME. Let’s Encrypt raccomanda ACME Renewal Information (ARI) oppure di rinnovare a circa due terzi della durata del certificato, e avverte che un intervallo fisso di 60 giorni non basterà più quando i certificati dureranno 45 giorni. Dopo una migrazione, verifica che la nuova piattaforma rinnovi davvero. Un singolo handshake mostra solo il protocollo negoziato: usa uno scanner che elenchi tutte le versioni supportate per confermare che TLS 1.0 e 1.1 siano disattivati.

Per capire come certificato, HSTS e le altre protezioni del browser si combinano durante una visita HTTPS, leggi la guida al funzionamento di HTTPS.

5. Redirect HTTPS: un solo passaggio a HTTPS, un host canonico, poi HSTS

Perché conta. Vecchi link, segnalibri, script e client datati richiedono ancora indirizzi http://. Un redirect li porta su HTTPS ma, come osserva hstspreload.org, un attaccante sul percorso può intercettare e riscrivere quel redirect. HSTS chiude il varco per ogni visita successiva alla prima sicura.

Come verificare.

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sIL "http://example.com/page?x=1" | grep -iE '^(HTTP|location)'

Come appare un buon risultato.

• Un redirect permanente (301, oppure 308 per mantenere il metodo della richiesta) verso lo stesso percorso su HTTPS e sullo stesso host, come consiglia la guida TLS di MDN, poi al massimo un ulteriore passaggio verso l’host canonico. Percorso e query string vengono conservati.
• La risposta HTTPS invia Strict-Transport-Security. I browser ignorano l’header su HTTP semplice, quindi il redirect stesso non ne ha bisogno.
• Nessun contenuto misto: i browser bloccano gli script caricati via http:// nelle pagine HTTPS.

Correzione tipica. Imposta il redirect nel server o nel CDN, non in JavaScript. Alza il max-age di HSTS per gradi fino a un valore lungo come 31536000 (un anno) e aggiungi includeSubDomains solo quando ogni sottodominio serve HTTPS. hstspreload.org ora raccomanda HSTS ma non il preloading. Se i certificati usano la sfida ACME HTTP-01, tieni raggiungibile la porta 80. Per testare questo punto con lo snapshot gratuito, inserisci l’indirizzo http://; con un dominio senza schema o un indirizzo https:// controlla invece il max-age di HSTS e i contenuti misti.

6. Header di sicurezza: controlla la risposta finale e le pagine di errore

Perché conta. Gli header di sicurezza dicono al browser che cosa una pagina può caricare, chi può inserirla in un frame e come trattare i tipi di contenuto. Spesso risiedono nella configurazione del server o del CDN, quindi un cambio di hosting può farli perdere. Limitano i danni di bug come il cross-site scripting; non correggono i bug.

Come verificare.

curl -sIL https://example.com/
curl -sI https://example.com/no-such-page

Controlla anche la pagina di errore: senza il parametro always, nginx invia i valori di add_header solo con certi codici di stato, come nota la OWASP HTTP Headers Cheat Sheet.

Come appare un buon risultato. Un insieme di partenza ragionevole per un sito semplice:

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

• Introduci la CSP prima come Content-Security-Policy-Report-Only. Deve consentire tutto ciò che le tue pagine caricano legittimamente, e 'unsafe-inline' vanifica gran parte del suo scopo.
• frame-ancestors non eredita da default-src e viene ignorato in un tag <meta>; X-Frame-Options: DENY è il vecchio ripiego.
• I cookie di sessione hanno Secure, HttpOnly e un SameSite esplicito (vedi MDN su Set-Cookie). HttpOnly impedisce agli script della pagina di leggere il cookie (per esempio tramite document.cookie), ma il browser lo invia comunque con le richieste corrispondenti: limita quindi il furto del cookie tramite XSS senza impedire l’XSS stesso.
• Nessun header X-XSS-Protection, oppure impostato a 0.

Correzione tipica. Imposta gli header in un solo livello (server, applicazione o CDN) così che ogni risposta, pagine di errore comprese, riceva ciascun header una sola volta. La guida alla verifica degli header di sicurezza spiega ogni header nel dettaglio, e la verifica gratuita degli header di sicurezza valuta otto header principali sulla home page di un sito pubblico; controlla le pagine di errore con curl come mostrato sopra.

7. Esposizione della tecnologia, cache e compressione

Esposizione della tecnologia

Perché conta. Server, X-Powered-By e i tag generator rivelano a chiunque il software in uso, e MDN osserva che numeri di versione dettagliati possono facilitare la ricerca di vulnerabilità note. Nasconderli è igiene, non protezione: la guida ai test di OWASP la definisce security through obscurity, e MDN indica l’aggiornamento come approccio più solido.

Come verificare. Esegui curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):', poi cerca nel sorgente della pagina generator e i nomi dei file script che includono numeri di versione.

Come appare un buon risultato. Server: nginx senza numero di versione e nessun X-Powered-By.

Correzione tipica. server_tokens off; in nginx, expose_php = Off in php.ini, app.disable('x-powered-by') in Express. Se una pagina rivela una libreria obsoleta, aggiornala invece di nasconderla.

Cache, compressione e CDN

Perché conta. Le regole di cache decidono chi riceve una copia salvata di una risposta. Una pagina personale messa in cache da un CDN può essere servita al visitatore successivo, ed è per questo che MDN afferma che le risposte personalizzate richiedono Cache-Control: private.

Come verificare. Esegui curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/, poi accedi, apri una pagina dell’account e leggi gli header della risposta negli strumenti per sviluppatori del browser.

Come appare un buon risultato. HTML servito con Content-Encoding: br o gzip; un Cache-Control esplicito su ogni risposta; un max-age lungo con immutable solo sui file statici versionati; private o no-store sulle pagine con dati dell’utente (no-cache consente comunque la memorizzazione).

Correzione tipica. Imposta Cache-Control per tipo di route, tieni i percorsi autenticati fuori dalla cache del CDN e comprimi il testo sul server o sul CDN. Non avere un CDN non è un rischio in sé; la guida alle prestazioni del sito tratta la velocità.

8. Registrazione del dominio: scadenza, blocco e contatti

Perché conta. Quando scade un dominio con un dominio di primo livello generico come .com, l’Expired Registration Recovery Policy di ICANN impone al registrar di interromperne per un periodo la risoluzione DNS, quindi sito ed email smettono di funzionare insieme. I promemoria di rinnovo vanno al contatto registrato, che può essere un ex dipendente o una casella sullo stesso dominio in scadenza.

Come verificare. Usa lo strumento di consultazione di ICANN. Dal 28 gennaio 2025 RDAP è la fonte definitiva dei dati di registrazione per i domini di primo livello generici; WHOIS è ancora richiesto solo per .com, .name e .post. Per i domini di codice paese usa la consultazione del registro o del registrar. Poi accedi all’account del registrar e controlla le impostazioni.

Come appare un buon risultato.

• Scadenza a mesi di distanza, rinnovo automatico attivo e un metodo di pagamento ancora valido alla data del rinnovo.
• clientTransferProhibited impostato, più i blocchi di aggiornamento ed eliminazione dove il registrar li offre; nessun clientHold o serverHold, che escludono il dominio dal DNS.
• Contatti che raggiungono più di una persona, con almeno un indirizzo non sul dominio stesso, e accesso con autenticazione a più fattori sull’account del registrar.

Correzione tipica. Attiva il rinnovo automatico, rinnova per più anni, chiedi al registrar di impostare gli stati di blocco (la guida ai codici di stato EPP di ICANN spiega ciascuno) e aggiorna i contatti.

9. Che cosa questa checklist non copre

Questi otto punti descrivono la configurazione pubblica intorno al sito. Un sito può superarli tutti ed essere comunque facile da violare, perché nessuno di essi guarda l’applicazione o come viene gestita. Rivedi separatamente:

• Vulnerabilità dell’applicazione: injection, cross-site scripting nei template, upload non sicuri, accessi tra account.
• Autenticazione e sessioni: accesso, reimpostazione della password, autenticazione a più fattori, pannelli di amministrazione.
• Dipendenze e server: plugin del CMS, pacchetti, patch del sistema operativo.
• Segreti e accessi: chiavi nei repository o nei bundle del front-end, e chi può raggiungere produzione, provider DNS e registrar.
• Backup: un ripristino che hai davvero provato.

La guida all’audit di sicurezza del sito approfondisce accesso, permessi e gli altri controlli lato applicazione, e la OWASP Web Security Testing Guide fornisce casi di test dettagliati.

Un primo passaggio rapido su un’origine. Lo snapshot gratuito di preparazione al lancio non richiede account. Per un’origine pubblica legge DNS pubblico, record DNS della posta, dati di registrazione del dominio, handshake TLS e risposta HTTP della home page, e non invia exploit, scansioni di porte, tentativi di accesso né carico. Ottieni un punteggio, un voto di hardening, il conteggio dei segnali di rischio e dei controlli superati, e fino a tre segnali da guardare per primi. Non è un pentest: un buon punteggio significa che questi segnali pubblici apparivano sani in quel momento. Il piano Free include solo i controlli di sicurezza; con i crediti audit un workspace Free può eseguire singoli audit nelle altre aree (ogni nuovo workspace Free parte con 1 credito per area). Tutte e sei le aree di audit (sicurezza, SEO tecnica, visibilità AI, accessibilità, prestazioni, integrazioni) sono incluse a partire dal piano Starter, da $49/mese.

Per vedere l’intero flusso nell’app, Stepthrough ha pubblicato su learn.ynteractive.com un tutorial passo passo con schermate reali. Copre la verifica della proprietà del sito, l’esecuzione degli audit di sicurezza, SEO tecnica, visibilità AI, accessibilità e prestazioni e la definizione delle priorità tra i risultati.