Cosa dovrebbero sapere anche i committenti di siti web — usare la 'Guida per rendere sicuro il proprio sito web' dell'IPA come checklist
· Aggiornato il: · Go Komura · Sviluppo di siti web, Sicurezza informatica, Vulnerabilità, SQL Injection, Cross-Site Scripting, IPA, WordPress, B2B
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 è How to Secure Your Website 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 attuale è la 7ª edizione riveduta, pubblicata a marzo 2021, per un totale di 115 pagine. Oltre al PDF, sono pubblicate anche pagine HTML per ogni singola vulnerabilità.
È organizzata in tre capitoli.
| Capitolo | Contenuto |
|---|---|
| Capitolo 1: Implementazione della sicurezza nelle applicazioni web | Copre minacce e contromisure (soluzioni fondamentali e misure di fallback) per 11 categorie di vulnerabilità |
| Capitolo 2: Sforzi per migliorare la sicurezza del sito web | Copre sforzi oltre l’implementazione dell’applicazione — come le operazioni sul server — che aumentano la sicurezza del sito nel complesso |
| Capitolo 3: Casi di errore | Copre 8 errori reali comuni, con esempi di codice sorgente e correzioni |
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.
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.
| Vulnerabilità | Cosa succede se non si interviene |
|---|---|
| SQL injection | Il contenuto del database — storico richieste, informazioni sui soci e così via — viene rubato o sovrascritto |
| OS command injection | Il server viene conquistato e usato come trampolino per ulteriori attacchi |
| Parametri di percorso non controllati (directory traversal) | Vengono letti file sul server che non avrebbero dovuto essere accessibili |
| Gestione sessioni impropria | Qualcun altro può accedere impersonando l’utente legittimo |
| Cross-site scripting (XSS) | Nella schermata del visitatore vengono eseguiti schermate false o processi malevoli, rubando informazioni |
| CSRF (cross-site request forgery) | Un utente loggato compie un’azione non voluta senza accorgersene |
| HTTP header injection | Viene sfruttata per mostrare pagine false o reindirizzare a un altro sito |
| Mail header injection | Il modulo di contatto viene abusato come dispositivo per inviare spam |
| Clickjacking | Pulsanti invisibili vengono sovrapposti, inducendo l’utente a cliccare qualcosa di non voluto |
| Buffer overflow | Il programma viene conquistato e fatto eseguire codice arbitrario |
| Mancato controllo di accesso o autorizzazione | Pagine riservate ai soci o funzioni di amministrazione diventano raggiungibili da persone non autorizzate |
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.
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.
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.
Da dove iniziare con la sicurezza per le PMI? — Guida alla 'Linea guida per la sicurezza informatica delle PMI' dell'IPA, 4ª edizione
Da dove devono iniziare le piccole e medie imprese con la sicurezza? Basandosi sulla 'Linea guida per la sicurezza informatica delle PMI'...
10 minacce maggiori alla sicurezza informatica 2026 — Come leggere la classifica e cosa dovrebbero difendere le PMI
Nelle '10 minacce maggiori alla sicurezza informatica 2026' dell'IPA, gli attacchi ransomware occupano il primo posto per l'undicesimo an...
Non dimenticare di decidere 'in quanti secondi è abbastanza veloce' — Organizzare i requisiti non funzionali con il Non-Functional Requirements Grade dell'IPA
Le dispute del tipo 'è troppo lento' o 'non ci aspettavamo quella reazione al guasto' di solito risalgono a requisiti non funzionali che ...
Il Sussidio per investimenti di risparmio del lavoro può pagare lo spostamento degli ordini fax sul web? — Come ragionare sull'investimento per l'ordine sistema nella categoria generale
Spostare la ricezione ordini fax sul web e automatizzarne l'import può essere un candidato per il Sussidio per investimenti di risparmio ...
Come gestire un progetto di sviluppo sistema finanziato da un sussidio — Lavorare all'indietro dalla data di decisione sul sussidio e le pratiche per scrivere il business plan
Un progetto di sviluppo sistema finanziato da un sussidio procede in modo diverso da uno ordinario. Questo articolo tratta, in termini pr...
Argomenti correlati
Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.
Argomenti tecnici Windows
Portale su sviluppo Windows, analisi dei problemi e valorizzazione delle risorse esistenti.
Argomenti su Web e SEO
Creazione di siti, SEO, percorso di contatto e progettazione dei collegamenti interni.
Servizi collegati all’argomento
L’articolo è direttamente collegato ai servizi seguenti.
Sviluppo di siti web
Per una nuova realizzazione o un rinnovo, le considerazioni di sicurezza trattate in questo articolo — come è implementato il modulo e come è configurato il CMS — influiscono direttamente sulla qualità del prodotto finito.
Consulenza tecnica e revisione del progetto
Identificare dove risiede effettivamente il rischio in un sito o sistema web esistente, e come scrivere i requisiti di sicurezza in una specifica di ordine, rientra in una consulenza tecnica che include design review.
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.