Un lucchetto verde nella barra degli indirizzi non garantisce granché. Qualsiasi sito può ottenere un certificato SSL gratuito, comprese le pagine di phishing. Verificare la sicurezza di un sito web richiede di andare oltre questo semplice indicatore visivo, esaminando strati che né il browser né l’utente medio vedono.
Sicurezza delle API: il punto cieco di un audit di sito web
Stai consultando una pagina web, vedi del testo, delle immagini, un modulo. Dietro le quinte, questa pagina interroga spesso diverse API per recuperare o inviare dati. Queste interfacce programmatiche sono diventate un obiettivo prioritario per gli attaccanti.
I rapporti del 2024 confermano che gli attacchi mirati alle API rappresentano una quota crescente degli incidenti sulle applicazioni web. Il problema: la maggior parte delle verifiche classiche si limita alle pagine visibili. Gli endpoint delle API, invece, rimangono nell’ombra.
Un audit efficace inizia con un inventario completo di questi endpoint. Alcuni sono stati creati per un bisogno occasionale, poi dimenticati. Altri sono documentati in modo incompleto. Sono proprio questi a creare problemi, perché nessuno pensa di controllare la loro autenticazione o le loro autorizzazioni.
Concretamente, ogni punto d’ingresso delle API deve essere testato singolarmente. Si verifica che l’autenticazione funzioni oggetto per oggetto (un utente A non deve poter accedere ai dati dell’utente B), che siano in atto dei limiti di velocità e che le API deprecate siano state effettivamente rimosse. Diversi strumenti consentono di automatizzare una parte di questa verifica della sicurezza dei siti web, ma la revisione manuale rimane necessaria per i controlli di autorizzazione.
Prioritizzare le vulnerabilità: perché il punteggio CVSS non basta
Quando uno scanner restituisce un elenco di vulnerabilità, ognuna è accompagnata da un punteggio di gravità (CVSS). La tentazione è di affrontare prima i punteggi più alti. Questo approccio sembra logico, ma perde un dato fondamentale: gli attaccanti sfruttano soprattutto vulnerabilità conosciute e documentate, non necessariamente le più sofisticate.
La CISA mantiene un catalogo chiamato Known Exploited Vulnerabilities (KEV). Esso elenca le vulnerabilità attivamente sfruttate in natura. Una vulnerabilità con un punteggio CVSS medio ma presente in questo catalogo merita una correzione immediata. Al contrario, una vulnerabilità teorica con un punteggio molto alto ma mai sfruttata può attendere.
Per una verifica realmente utile, incrocia tre criteri:
- La gravità tecnica data dal punteggio CVSS, che misura il potenziale danno della vulnerabilità.
- La presenza nel catalogo KEV della CISA, che indica se la vulnerabilità è attivamente sfruttata dagli attaccanti.
- L’esposizione reale del componente interessato: un servizio accessibile da internet è più urgente di uno strumento interno dietro un VPN.
Incrociare gravità tecnica, sfruttamento attivo ed esposizione reale cambia radicalmente l’ordine di priorità delle correzioni. Senza questa selezione, un’azienda può passare settimane su una vulnerabilità teorica mentre una breccia sfruttata rimane aperta.
Componenti open source e modelli di IA nell’analisi di sicurezza
La maggior parte dei siti web moderni si basa su librerie open source. Un CMS, un framework JavaScript, un modulo di pagamento: ognuno include codice di terzi con le proprie vulnerabilità potenziali.
Verificare questi componenti richiede un inventario preciso, spesso chiamato Software Bill of Materials (SBOM). Questo documento elenca ogni dipendenza, la sua versione e il suo stato di manutenzione. Un componente abbandonato dai suoi manutentori è un rischio silenzioso: nessun aggiornamento correggerà le vulnerabilità scoperte dopo l’abbandono.
Le funzionalità che integrano intelligenza artificiale pongono un problema aggiuntivo. Un modello di IA esposto tramite un’API può essere manipolato da richieste progettate per estrarre dati di addestramento o aggirare filtri. Questi vettori d’attacco sono ancora poco coperti dagli scanner classici.
Verificare la configurazione del server e le intestazioni HTTP
Anche prima di cercare vulnerabilità nel codice, la configurazione del server rivela spesso problemi semplici da correggere. Le intestazioni HTTP, ad esempio, controllano come il browser interagisce con il sito.
Un’intestazione Content-Security-Policy ben configurata blocca la maggior parte degli attacchi XSS. Al contrario, alcune intestazioni un tempo raccomandate sono ora obsolete. X-XSS-Protection, ad esempio, non è più utile nei browser moderni secondo la documentazione MDN. Copiare e incollare una configurazione trovata su un forum del 2018 può dare un falso senso di sicurezza.
I punti da verificare lato server:
- Il protocollo HTTPS è attivo con un certificato valido, e i reindirizzamenti HTTP verso HTTPS funzionano senza loop.
- I file sensibili (backup, file di configurazione, directory .git) non sono accessibili pubblicamente.
- Le intestazioni di sicurezza sono aggiornate e adatte al contesto del sito, non semplicemente copiate da un modello generico.
- I messaggi di errore del server non rivelano informazioni tecniche (versioni di software, percorsi di file).
Verifica dopo correzione: il passo che la maggior parte delle aziende salta
Rilevare una vulnerabilità, correggerla, passare alla successiva. Questo ciclo sembra completo, ma manca un passaggio formale: confermare che la correzione funzioni realmente.
I dati del 2024 mostrano che vulnerabilità conosciute rimangono aperte per periodi prolungati, anche in aziende dotate di scanner. La correzione è stata distribuita in un ambiente di test ma non in produzione. Oppure l’aggiornamento è stato applicato, ma una versione vulnerabile del componente è ancora in esecuzione su un altro server.
La verifica dopo correzione deve includere una nuova scansione mirata sulla vulnerabilità trattata, una verifica manuale che la correzione non abbia creato regressioni (una funzionalità rotta, un modulo che non valida più le voci) e un controllo che le versioni vulnerabili siano state rimosse da tutti gli ambienti esposti.
Questo passaggio trasforma un rapporto di audit in un miglioramento misurabile. Senza di esso, il rapporto rimane un documento PDF archiviato in una cartella, e la vulnerabilità rimane sfruttabile.
