Cosa dovrebbero sapere anche i committenti di siti web — usare la 'Guida per rendere sicuro il proprio sito web' dell'IPA come checklist

Chiedere “la sicurezza del nostro sito web è a posto?” e poche aziende possono rispondere “sì” con una reale base di giudizio.

È facile presumere che vada tutto bene perché se ne occupa una web agency, o che un sito solo con profilo aziendale non sia un bersaglio — ma un solo modulo di contatto significa che gira un programma che elabora input, e se si usa un CMS come WordPress, sia la schermata di amministrazione che ogni plugin sono superfici di attacco. Inoltre la maggior parte degli attacchi non mirano a un’azienda specifica; scansionano meccanicamente siti deboli.

Quindi, contro quale standard controllare concretamente se “è a posto”? Il riferimento pubblico che da tempo svolge questo ruolo è la Guida per rendere sicuro il proprio sito web dell’IPA (Information-technology Promotion Agency).

Questo articolo espone cosa insegna questo riferimento, con un linguaggio comprensibile sia al committente dell’ordine sia a chi gestisce il sito.

1. La linea di fondo per prima

• La “Guida per rendere sicuro il proprio sito web” è un riferimento costruito sulle vulnerabilità effettivamente segnalate all’IPA, riassumendo 11 categorie di debolezza dei siti web e le relative contromisure. È utile non solo per gli sviluppatori, ma come standard per l’ordine e il collaudo
• Le contromisure si dividono in “soluzione fondamentale” (rimuove la causa) e “misura di fallback” (riduce il danno). La baseline è la soluzione fondamentale, con le misure di fallback a strato aggiuntivo
• La “Checklist di implementazione della sicurezza” allegata si può usare direttamente come voce di verifica sia in fase di ordine che di collaudo
• Il supplemento “Specifica di health-check del sito web” fornisce una baseline di voci diagnostiche per ispezionare periodicamente un sito in produzione
• In pratica, per un sito aziendale, il rischio si concentra nelle parti che accettano input, come i moduli, e nelle operazioni del CMS (WordPress e simili). Decidere al momento dell’ordine una struttura operativa continuativa, così il progetto non finisce nel momento in cui il sito viene consegnato

2. Cos’è la “Guida per rendere sicuro il proprio sito web”?

La “Guida per rendere sicuro il proprio sito web” è un riferimento che l’IPA ha compilato per sviluppatori e operatori di siti web, coprendo vulnerabilità segnalate frequentemente oppure con grande impatto se sfruttate, insieme alle contromisure. La versione più recente attualmente pubblicata è la 7ª edizione riveduta, per un totale di 115 pagine; il PDF distribuito è stato aggiornato il 31 marzo 2021 come 4ª ristampa. Oltre al PDF, sono pubblicate anche pagine HTML per ogni singola vulnerabilità.

È organizzata in tre capitoli.

Oltre al volume principale, sono pubblicati anche:

• Checklist di implementazione della sicurezza (formato Excel): un elenco per confermare se le contromisure del volume principale sono state implementate
• Volume supplementare “Come chiamare SQL in modo sicuro”: approfondimento sulle contromisure per le vulnerabilità relative ai database
• Volume supplementare “Specifica di health-check del sito web”: specifica di 13 voci diagnostiche per valutare un sito in esercizio

Tutti questi materiali sono scaricabili gratuitamente dalla pagina dell’IPA.

2.1. Come valutare l’attualità del documento

Prima di usare questo riferimento come standard, c’è una premessa da tenere presente. La 7ª edizione riveduta è stata pubblicata a marzo 2015; da allora ogni ristampa ha portato correzioni, e il PDF attualmente distribuito è la 4ª ristampa della 7ª edizione, aggiornata il 31 marzo 2021. Al momento in cui scriviamo (luglio 2026) non è stata pubblicata alcuna 8ª edizione.

Resta comunque utilizzabile come standard perché ciò di cui tratta sono debolezze che nascono dal modo stesso in cui si costruisce un’applicazione web. Incorporare valori di input in istruzioni SQL o in HTML, identificare l’utente tramite una sessione, inviare email a partire dall’input di un modulo: questi meccanismi non sono cambiati. Le 11 categorie di vulnerabilità e il ragionamento “soluzione fondamentale / misura di fallback” valgono ancora oggi come criterio di verifica dell’implementazione.

Di converso, le tendenze recenti delle minacce non sono coperte da questo documento. Attacchi ransomware, intrusioni instradate attraverso partner commerciali o fornitori, rischi legati all’uso dell’IA generativa: questi temi non sono mai rientrati nel suo perimetro. Vanno integrati con documenti che vengono aggiornati ogni anno.

Non serve leggere i tre documenti separatamente. Basta distinguerne i ruoli — “lo standard di implementazione è questo documento, le tendenze aggiornate delle minacce sono nelle 10 minacce maggiori, l’assetto aziendale è nella linea guida” — e consultare solo ciò che serve al momento. I contenuti dell’edizione 2026 delle 10 minacce maggiori sono trattati nel nostro articolo sulle 10 minacce maggiori 2026, mentre l’edizione 4.0 della linea guida è trattata nel nostro articolo sulla 4ª edizione delle linee guida.

3. Leggere le 11 vulnerabilità come “cosa succede se non si fa nulla”

Le 11 categorie di vulnerabilità trattate nel Capitolo 1 sono espresse in terminologia da sviluppatori, ma se le si riformula come “cosa succede sul proprio sito se lo si lascia stare”, si capisce che non sono un problema di qualcun altro nemmeno per il committente dell’ordine.

La colonna di destra riporta esempi dei punti in cui la vulnerabilità tende a diventare un problema in un sito aziendale. Verificando se il proprio sito ha le stesse funzioni si riconosce quali righe riguardano davvero la propria azienda.

Per esempio, la “mail header injection” si applica direttamente al modulo di contatto di un sito aziendale minimale. Un modulo mal protetto viene abusato come sorgente di spam, danneggiando anche la reputazione del dominio aziendale stesso (indipendentemente dal fatto che le sue email vengano effettivamente consegnate). Come trattato in “Perché le email del modulo di contatto non vengono consegnate”, un modulo le cui email smettono di arrivare si traduce direttamente in opportunità di business perse.

4. “Soluzioni fondamentali” e “misure di fallback” — come ragionare sulle contromisure

Ciò che rende eccellente questo riferimento è che presenta le contromisure in due categorie.

• Soluzione fondamentale: un’implementazione che rimuove la causa principale della vulnerabilità stessa. Per l’SQL injection, per esempio, costruire le istruzioni SQL con placeholder invece di concatenazione di stringhe
• Misura di fallback: una contromisura che riduce la probabilità di successo o l’impatto di un attacco quando una vulnerabilità rimane. Per esempio, non mostrare messaggi di errore grezzi nel browser

Questa distinzione offre al committente un metro di giudizio quando ascolta una spiegazione sulla sicurezza. Una frase come “mettiamo un WAF (meccanismo che rileva e blocca gli attacchi), quindi siete coperti” parla di una misura di fallback — non è un sostituto della soluzione fondamentale nell’applicazione stessa. Viceversa, implementare una soluzione fondamentale e poi aggiungere un WAF sopra è una configurazione solida. Saper distinguere a quale strato si riferisce chi parla permette di giudicare notevolmente meglio la solidità di una proposta.

5. Come usarla in fase di ordine e collaudo

La “Guida per rendere sicuro il proprio sito web” è scritta per sviluppatori, ma il suo valore pratico per il committente sta nel fatto che può essere usata come standard per requisiti e verifica.

• In fase di preventivo / specifica: aggiungere una riga che dica “implementare le contromisure per le vulnerabilità elencate nella ‘Guida per rendere sicuro il proprio sito web’ dell’IPA”. Citare uno standard specifico rende il requisito molto più concreto di una frase generica come “prestare adeguata attenzione alla sicurezza”
• In fase di collaudo: chiedere i risultati di conferma rispetto alle voci pertinenti della checklist di implementazione della sicurezza
• In fase contrattuale: mettere per iscritto chi gestirà gli aggiornamenti del CMS, dei plugin e del server dopo il go-live, e se la risposta a una nuova vulnerabilità rientra nel contratto di manutenzione o richiede un preventivo separato

Il terzo punto conta soprattutto. La sicurezza di un sito web non finisce nel momento in cui viene consegnato — si mantiene tenendo il passo con le nuove vulnerabilità scoperte dopo il go-live. Questa domanda su “chi continua a vigilarci” ha la stessa struttura della questione di ambito di manutenzione trattata nel nostro articolo sui contratti di sviluppo e manutenzione affidati a terzi.

5.1. Esempi di formulazione per la specifica o l’RFP

Con “prestare attenzione alla sicurezza” non si stabilisce in base a cosa si possa dire che il requisito è soddisfatto. Indicando il nome del documento di riferimento e i deliverable da consegnare, la richiesta assume una forma verificabile. Per esempio, si può scrivere così.

Requisiti di sicurezza

1. L’applicazione web oggetto del presente incarico deve implementare, per ciascuna vulnerabilità elencata nel Capitolo 1 della “Guida per rendere sicuro il proprio sito web, 7ª edizione riveduta” dell’IPA, le contromisure classificate come “soluzione fondamentale” nello stesso documento.
2. Alla consegna deve essere presentato l’esito dell’autoverifica su tutte le voci della “Checklist di implementazione della sicurezza” allegata al medesimo documento. Per le voci giudicate “non applicabili” va indicata anche la ragione (per esempio, l’assenza della funzione corrispondente).
3. Per le schermate che comportano elaborazioni dinamiche (modulo di contatto, ricerca, login, download di file e simili) devono essere riportati nella documentazione di progetto il trattamento dei valori di input e i criteri di escaping in output.
4. Nel contratto di manutenzione devono essere indicati esplicitamente chi effettuerà gli aggiornamenti del core del CMS, dei temi, dei plugin e dell’ambiente di esecuzione dopo il go-live e con quale frequenza, nonché i tempi di intervento e il trattamento dei costi nel caso in cui venga resa pubblica una vulnerabilità urgente.

Non è necessario inserire tutti e quattro i punti fin dall’inizio. Per un sito incentrato sulla presentazione aziendale bastano anche solo il primo e il secondo: la conversazione al collaudo sarà comunque del tutto diversa rispetto a un ordine affidato con un “alla sicurezza pensateci voi”.

5.2. Cosa contiene la checklist

La checklist è un unico file Excel in cui 47 voci di attuazione, corrispondenti al Capitolo 1 della “Guida per rendere sicuro il proprio sito web, 7ª edizione riveduta”, sono elencate per ciascuna delle 11 categorie di vulnerabilità. Ogni riga è composta dal tipo di vulnerabilità, dalla natura della contromisura (soluzione fondamentale / misura di fallback), dalla casella di controllo (attuata / non attuata / non applicabile), dal testo della voce di attuazione e dal numero della spiegazione nel volume principale.

Le voci reali sono formulate, per esempio, con frasi come le seguenti.

(Il testo delle voci di attuazione è citato dalla Checklist di implementazione della sicurezza allegata alla “Guida per rendere sicuro il proprio sito web, 7ª edizione riveduta” dell’IPA.)

Ciò che rende la checklist comoda per il committente è la presenza della casella “non applicabile”. In un sito privo di funzione di login è normale che le voci sulla gestione delle sessioni restino vuote, ma se non viene scritto nulla non si distingue se si tratti di un “non applicabile perché la funzione non esiste” o di una svista. Basta farsi indicare “non applicabile” insieme alla motivazione perché la conversazione al collaudo diventi concreta.

6. Dare a un sito in produzione un “health check”

Per un sito già in produzione, è utile il supplemento “Specifica di health-check del sito web”. È una specifica di voci diagnostiche (13 in totale) per controllare la sicurezza di un sito web in esercizio, e funge anche da guida approssimativa per l’ambito di copertura di un servizio di diagnosi delle vulnerabilità.

Per un sito aziendale di una PMI, in pratica il rischio tende a concentrarsi in due punti in particolare:

• Le parti che accettano input: moduli di contatto, caselle di ricerca, login per i soci e così via. La maggior parte delle vulnerabilità del Capitolo 1 riguarda queste
• Le operazioni del CMS: in un sito in cui gli aggiornamenti del core, del tema o dei plugin di un CMS come WordPress sono rimasti fermi, la classica modalità di manomissione sfrutta una debolezza nota. È estremamente comune che nessuno abbia deciso di chi sia il compito degli aggiornamenti e il sito venga semplicemente lasciato così com’è

Se si vuole ripensare all’onere degli aggiornamenti del CMS insieme all’intera struttura operativa, vale la pena dare un’occhiata anche al nostro articolo sulla migrazione da WordPress. C’è anche la scelta progettuale di ridurre complessivamente l’elaborazione dinamica favorendo una struttura di sito statico, che restringe la superficie di attacco stessa. Il nostro uso di una struttura di sito statico costruita sul design system della Digital Agency per la produzione dei siti è un’estensione dello stesso ragionamento.

Notare che operare un sito web in sicurezza è elencato come voce di controllo anche nell’autovalutazione della “Linea guida per la sicurezza informatica delle PMI” dell’IPA, edizione 4.0. Per dove collocare questo aspetto all’interno delle misure di sicurezza complessive dell’azienda, vedere il nostro articolo sulla 4ª edizione delle linee guida.

7. Mini glossario dei termini

Riepiloghiamo qui i termini usati in questo articolo tra quelli che compaiono nelle riunioni con la web agency. Se si riesce a esprimerne il significato in una riga, mentre si ascolta una spiegazione si può giudicare da soli se si stia parlando di una soluzione fondamentale o di una misura di fallback.

Riepilogo

Ecco i punti chiave della “Guida per rendere sicuro il proprio sito web” dell’IPA.

• Un riferimento standard (7ª edizione riveduta, 115 pagine) che copre 11 categorie di debolezza dei siti web e le relative contromisure, basato su vulnerabilità effettivamente segnalate all’IPA
• Le contromisure si dividono in due strati: soluzioni fondamentali e misure di fallback. Una misura di fallback come un WAF non sostituisce una soluzione fondamentale
• Il committente può usarla citando il riferimento nei requisiti, verificando il collaudo con la checklist e regolando per iscritto la struttura post-go-live nel contratto
• Dare periodicamente health check al sito in produzione usando la “Specifica di health-check” come baseline
• Per un sito aziendale, il rischio realistico tende a concentrarsi nell’elaborazione degli input come i moduli e in un CMS trascurato

La sicurezza tende a diventare una scelta tra “spendere quanto dice l’esperto” o “non fare nulla”, ma semplicemente conoscere gli standard pubblici permette di formulare richieste e verificare risultati con parole proprie.

Per chi sta considerando di realizzare o rinnovare un sito web

In fase di realizzazione o rinnovo di un sito web, Komura Software LLC propone soluzioni coerenti con il ragionamento di questo articolo — da come è implementato il modulo, a una struttura statica che non dipenda eccessivamente da un CMS, fino alla struttura operativa post-go-live. Accogliamo anche una consulenza a partire da una valutazione dello stato attuale per chi non è nemmeno sicuro di quale sia lo stato del proprio sito attuale.

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Che tipo di documento è la 'Guida per rendere sicuro il proprio sito web'?

È un riferimento sulla sicurezza pubblicato dall'IPA (Information-technology Promotion Agency) per sviluppatori e operatori di siti web. Tra le segnalazioni ricevute dall'IPA, copre le vulnerabilità più frequenti o con maggiore impatto, spiegando le minacce e le contromisure. L'attuale 7ª edizione riveduta è stata pubblicata a marzo 2021 e conta 115 pagine. Accanto al volume principale, l'IPA pubblica gratuitamente una checklist di implementazione della sicurezza e due volumi supplementari: 'Come chiamare SQL in modo sicuro' e la 'Specifica di health-check del sito web'.

Anche un sito aziendale minimale con solo profilo aziendale ha bisogno di misure di sicurezza?

Sì. Se c'è un modulo di contatto, un programma elabora l'input; se si usa un CMS come WordPress, sia la schermata di amministrazione che ogni plugin sono superfici di attacco. Gli aggressori non scelgono necessariamente il target in base alla dimensione aziendale; scansionano meccanicamente siti deboli e li abusano come trampolini di lancio per manomissioni, distribuzione di malware o invio di spam. Ciò che rende pericoloso un sito web è che, mentre se ne è vittima, si possono danneggiare contemporaneamente anche partner commerciali e visitatori.

Qual è la differenza tra soluzione fondamentale e misura di fallback?

La 'Guida per rendere sicuro il proprio sito web' presenta le contromisure in due categorie. Una soluzione fondamentale è un approccio implementativo che rimuove la causa principale della vulnerabilità (per esempio, usare placeholder invece della concatenazione di stringhe per costruire istruzioni SQL). Una misura di fallback riduce la probabilità di successo o l'impatto di un attacco quando la vulnerabilità rimane (per esempio, non mostrare messaggi di errore grezzi). Poiché le misure di fallback da sole lasciano la causa principale al suo posto, l'ordine corretto è considerare la soluzione fondamentale come baseline e aggiungere le misure di fallback sopra.

Cosa dovrei controllare sulla sicurezza quando ordino un sito a una web agency?

Al minimo, consigliamo di confermare tre cose in fase di preventivo: (1) se sono implementate le contromisure elencate nella 'Guida per rendere sicuro il proprio sito web' dell'IPA, (2) se i risultati possono essere mostrati usando la checklist di implementazione della sicurezza allegata o simile, e (3) chi gestirà gli aggiornamenti del CMS e dei plugin dopo il go-live (cioè se rientra nel contratto di operatività/manutenzione). I requisiti di sicurezza costano molto se aggiunti in corso d'opera, quindi è importante confermarli per iscritto prima della firma del contratto.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.