Uno scanner gratuito che verifica il certificato SSL e le intestazioni HTTP dà una falsa impressione di copertura. L’OWASP Top 10:2025 posiziona la Security Misconfiguration al secondo posto e introduce le Software Supply Chain Failures come categoria a sé stante. Testare la sicurezza di un sito web online implica comprendere cosa catturano realmente questi strumenti e, soprattutto, cosa ignorano.
Supply Chain e condizioni eccezionali: i punti ciechi degli scanner gratuiti
La maggior parte degli strumenti accessibili senza registrazione analizza la superficie esposta: validità del certificato TLS, presenza delle intestazioni Content-Security-Policy, X-Frame-Options, configurazione DNS. È una base utile, ma che non copre né la catena di dipendenze software né la gestione degli errori applicativi.
L’OWASP Top 10:2025 ha formalizzato questi due rischi sotto le categorie Software Supply Chain Failures e Mishandling of Exceptional Conditions. Un componente JavaScript importato tramite npm, un’immagine Docker costruita su una base non mantenuta, un pipeline CI/CD i cui segreti sono esposti: nessuna scansione esterna anonima rileva questi difetti.
Raccomandiamo di trattare la scansione online come un primo filtro, non come un audit. Essa identifica gli errori di configurazione visibili dall’esterno. Per la catena software, è necessario uno strumento di tipo Software Composition Analysis (Snyk Open Source, OWASP Dependency-Check) eseguito nel repository di codice.
Prima di avviare una scansione, è utile testare la sicurezza di un sito web online comprendendo precisamente il perimetro coperto da ogni strumento, per evitare di confondere un rapporto pulito con una superficie di attacco realmente ridotta.
Security Misconfiguration: cosa rilevano realmente le scansioni delle intestazioni HTTP
La salita della Security Misconfiguration al secondo posto nella classifica OWASP non è aneddotica. Essa riflette la moltiplicazione delle superfici di configurazione: bucket cloud pubblici, endpoint di amministrazione accessibili, pagine di errore verbose che espongono tracce di stack, cookie senza attributo Secure o SameSite.
Gli scanner gratuiti coprono una parte di questo perimetro. Verificano tipicamente:
- La presenza e il valore delle intestazioni di sicurezza HTTP (Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
- La configurazione TLS (versione del protocollo, suite di crittografia, scadenza del certificato)
- L’esposizione di informazioni sul server nelle intestazioni di risposta (Server, X-Powered-By)
- La politica CORS e le origini autorizzate
Al contrario, una scansione esterna non testa le configurazioni interne: regole IAM di un bucket S3, accesso a una console di amministrazione protetta da un URL oscuro, o variabili d’ambiente iniettate in chiaro nel codice sorgente lato client. Queste verifiche richiedono un accesso autenticato o un audit del codice distribuito.
Interpretare un punteggio di sicurezza senza sovrastimarlo
Un rapporto che mostra un punteggio elevato (A o A+) sulle intestazioni HTTP non significa che l’applicazione sia sicura. Significa che il livello di trasporto e le direttive del browser sono configurati correttamente. Osserviamo regolarmente siti valutati A+ il cui pannello di amministrazione è accessibile tramite /admin senza restrizioni IP o doppia autenticazione.
Il punteggio è un indicatore di maturità su un perimetro specifico. Non copre né la logica aziendale né i controlli di accesso applicativi.
Broken Access Control e test autenticati: il limite strutturale della scansione anonima
Il rischio classificato numero uno dall’OWASP nel 2025 rimane il Broken Access Control, che ora include anche il SSRF (Server-Side Request Forgery). Questo tipo di vulnerabilità richiede account di test con diversi livelli di privilegi e scenari aziendali concreti: un utente standard che tenta di accedere a una risorsa riservata a un amministratore, una richiesta API che modifica l’identificativo di un oggetto per raggiungere i dati di un altro utente (IDOR).
Nessuno scanner esterno anonimo può convalidare i controlli di accesso senza avere almeno due sessioni autenticate con ruoli diversi. Uno strumento come OWASP ZAP consente di configurare contesti di autenticazione e di riprodurre scenari, ma questo va oltre il semplice test online.
Approccio combinato per un audit realistico senza budget
Per coprire un perimetro accettabile senza investimento finanziario, raccomandiamo di combinare tre livelli:
- Una scansione delle intestazioni e della configurazione TLS tramite uno strumento online gratuito (Mozilla Observatory, SecurityHeaders.com) per il perimetro rete e trasporto
- Un proxy di intercettazione locale (OWASP ZAP in modalità standard) per testare manualmente i controlli di accesso e le iniezioni sui moduli, con sessioni autenticate
- Un’analisi delle dipendenze (npm audit, pip-audit, OWASP Dependency-Check) direttamente nel pipeline di build per coprire la catena software
Questa combinazione copre tre dei cinque principali rischi della classifica OWASP 2025. Non sostituisce un pentest professionale, ma eleva significativamente il livello di rilevamento rispetto a una scansione unica delle intestazioni HTTP.
CORS, cookie e Content-Security-Policy: le impostazioni da verificare in priorità
Tra gli elementi testabili gratuitamente, tre configurazioni concentrano una parte sproporzionata degli errori sfruttabili.
La politica CORS mal configurata rimane frequente. Un Access-Control-Allow-Origin impostato su * con Access-Control-Allow-Credentials a true espone i cookie di sessione a qualsiasi dominio terzo. Gli scanner gratuiti segnalano questa combinazione, ma non testano le conseguenze applicative.
Gli attributi dei cookie meritano particolare attenzione. Un cookie di sessione senza Secure, senza HttpOnly e senza SameSite=Strict (o Lax) è vulnerabile al furto tramite XSS o all’inclusione in richieste cross-site. I browser recenti attenuano alcuni scenari, ma la configurazione esplicita rimane l’unica protezione affidabile lato server.
Infine, una Content-Security-Policy permissiva annulla la protezione contro le iniezioni XSS. Una direttiva script-src contenente ‘unsafe-inline’ o ‘unsafe-eval’ rende la CSP cosmetica. Gli strumenti di scansione online rilevano queste direttive, rendendole uno dei pochi controlli applicativi accessibili senza autenticazione.
La gratuità di uno strumento di test non è di per sé un problema. Ciò che crea un falso senso di sicurezza è trattare il rapporto come esaustivo mentre copre solo una frazione della superficie di attacco reale. Una scansione pulita sulle intestazioni HTTP rimane un buon punto di partenza, a condizione di proseguire con i livelli che lo strumento non può raggiungere.
