Web e API
Test di sicurezza di siti web e API: il DAST spiegato
I test di sicurezza di siti web e API, spesso chiamati test dinamici di sicurezza delle applicazioni (DAST), inviano richieste costruite ad arte a un’applicazione in esecuzione e ne osservano le risposte, per trovare falle come un controllo degli accessi difettoso, injection ed errori di configurazione. Integrano l’analisi del codice e delle dipendenze, e vanno eseguiti solo su sistemi di tua proprietà o che sei autorizzato per iscritto a testare.
Piano Free, nessuna carta richiesta.
Che cos’è il test dinamico di sicurezza delle applicazioni (DAST)?
Il test dinamico tratta l’applicazione come una scatola nera, o grigia quando chi esegue il test dispone di credenziali. Uno strumento o una persona esplora il sito o legge la descrizione dell’API, poi invia richieste pensate per provocare errori: identificatori modificati, parametri inattesi, payload sovradimensionati, token mancanti o falsificati. Le rilevazioni nascono dal comportamento, non dal codice sorgente. È insieme il punto di forza e il limite del metodo: vede ciò che vede un attaccante, compresi i problemi di deployment e di configurazione, ma trova solo ciò che riesce a raggiungere.
Per le API, la copertura dipende dal conoscere gli endpoint. Una descrizione OpenAPI, una collection Postman o del traffico registrato permettono a un test di raggiungere operazioni che un crawler non troverebbe mai. Il test autenticato con almeno due account di ruoli diversi è ciò che rivela la falla in cima alla OWASP API Security Top 10: un utente che accede agli oggetti di un altro utente.
In cosa il DAST differisce dal SAST e dall’analisi delle dipendenze?
I tre metodi rispondono a domande diverse. L’analisi delle dipendenze ti dice se i componenti che distribuisci hanno vulnerabilità note. L’analisi statica ti dice se il tuo codice contiene pattern pericolosi. Il test dinamico ti dice se il sistema in produzione, con la sua configurazione, autenticazione e infrastruttura, può essere davvero sfruttato. Un programma maturo usa tutti e tre e si serve dei risultati dinamici per confermare quali rilevazioni statiche e sulle dipendenze sono sfruttabili nella pratica.
| Metodo | Cosa esamina | Rilevazioni tipiche | Punti ciechi |
|---|---|---|---|
| Analisi delle dipendenze | Lockfile, manifest, SBOM e immagini container | Vulnerabilità note e pacchetti malevoli nei componenti di terze parti | Falle nel tuo codice e nel modo in cui l’applicazione è messa in produzione |
| Analisi statica (SAST) | Il tuo codice sorgente, senza eseguirlo | Pattern di injection, funzioni non sicure, credenziali scritte nel codice | Configurazione a runtime e logica di autorizzazione distribuita tra più servizi |
| Test dinamico (DAST) | Il sito web o l’API in esecuzione, attraverso la rete | Controllo degli accessi difettoso, injection, errori di configurazione, endpoint esposti | Percorsi del codice che il test non riesce a raggiungere e la causa alla radice nel codice |
Perché limitare i test ai domini di tua proprietà o che sei autorizzato a testare?
Sulla rete un test di sicurezza e un attacco sono identici; la differenza è l’autorizzazione. Nell’UE, la direttiva 2013/40/UE impone agli Stati membri di punire come reato, almeno nei casi che non sono di minore gravità, l’accesso illecito a sistemi di informazione e l’interferenza illecita relativamente ai sistemi commessi intenzionalmente e «senza diritto». La direttiva definisce tale condotta come non autorizzata dal proprietario o da un altro titolare di diritti sul sistema, oppure non consentita dal diritto nazionale. Le leggi nazionali differiscono nei dettagli, ma la regola pratica è ovunque la stessa: senza autorizzazione scritta, nessun test.
Anche l’autorizzazione ha i suoi risvolti tecnici. Un sito su hosting condiviso, dietro una rete di distribuzione dei contenuti (CDN) o un gateway API di terzi coinvolge altri proprietari i cui termini possono limitare i test, e un test che sovraccarica un servizio condiviso può danneggiare altri clienti. Dimostrare il controllo di un dominio, per esempio con un record DNS o un file sul server web, è un modo comune con cui un servizio di test verifica che il richiedente abbia titolo per testarlo. Conserva agli atti, insieme ai risultati, l’autorizzazione, il perimetro, la finestra temporale del test e la persona di contatto.
Quali liste OWASP dovrebbero coprire i test di siti web e API?
La OWASP Top 10 e la OWASP API Security Top 10 sono i riferimenti abituali per definire il perimetro di un test. Sono documenti di sensibilizzazione più che standard di test completi, ma nominano le classi di falle che contano di più. Le edizioni attuali sono la OWASP Top 10:2025 per le applicazioni web e la OWASP API Security Top 10 2023 per le API.
Diverse categorie non si trovano con il solo test dinamico. I fallimenti della catena di fornitura del software sono in gran parte una questione di dipendenze e di build, e la gestione impropria dell’inventario comincia dal sapere quali versioni delle API e quali host sono in esercizio. È lì che l’analisi lato codice e un inventario accurato colmano la lacuna.
| Posizione | OWASP Top 10:2025 | OWASP API Security Top 10 2023 |
|---|---|---|
| 1 | Broken Access Control | Broken Object Level Authorization |
| 2 | Security Misconfiguration | Broken Authentication |
| 3 | Software Supply Chain Failures | Broken Object Property Level Authorization |
| 4 | Cryptographic Failures | Unrestricted Resource Consumption |
| 5 | Injection | Broken Function Level Authorization |
| 6 | Insecure Design | Unrestricted Access to Sensitive Business Flows |
| 7 | Authentication Failures | Server Side Request Forgery |
| 8 | Software or Data Integrity Failures | Security Misconfiguration |
| 9 | Security Logging and Alerting Failures | Improper Inventory Management |
| 10 | Mishandling of Exceptional Conditions | Unsafe Consumption of APIs |
Come si inseriscono i test di siti web e API nel CRA e nella NIS2?
Ai sensi del CRA, un prodotto con elementi digitali comprende le sue soluzioni di elaborazione dati da remoto: un’elaborazione dati a distanza, progettata e sviluppata dal fabbricante o sotto la sua responsabilità, senza la quale il prodotto non potrebbe svolgere una delle sue funzioni. I considerando del CRA fanno l’esempio di un’app mobile che ha bisogno di un’API fornita dal fabbricante; quell’API rientra nell’ambito di applicazione, mentre i siti web che non supportano la funzionalità di un prodotto no. L’allegato I, parte II, richiede prove e riesami efficaci e periodici della sicurezza del prodotto, che per un prodotto con un backend cloud possono ragionevolmente includere il test della sua API.
Il software offerto esclusivamente come servizio non rientra nel CRA; i considerando del CRA rimandano alla NIS2 per i servizi di cloud computing come il software as a service. L’articolo 21, paragrafo 2, lettera e), della NIS2 chiede ai soggetti essenziali e importanti la sicurezza dell’acquisizione, dello sviluppo e della manutenzione dei loro sistemi, compresa la gestione e la divulgazione delle vulnerabilità. Per alcuni fornitori di servizi digitali, il regolamento di esecuzione (UE) 2024/2690 aggiunge una politica documentata per i test di sicurezza, test la cui necessità, portata, frequenza e tipo derivano dalla valutazione dei rischi, e la registrazione del tipo, della portata, del momento e dei risultati di ogni test.
Disponibile oggi in KROMSE
KROMSE non testa ancora siti web o API in esecuzione, ma controlla il codice, le dipendenze e le immagini container che ci sono dietro.
- Controlli delle dipendenze rispetto a OSV.dev per i lockfile e i manifest alla base del tuo sito o della tua API, tra cui npm, Yarn, pnpm, Poetry, uv, pip, Go, Cargo, Maven, Gradle, Composer, Bundler e .NET.
- Analisi del codice sorgente per 11 linguaggi, tra cui JavaScript, TypeScript, Python, Java, Go e C#, più l’importazione dei tuoi risultati SARIF 2.1.0.
- Rilevamento dei segreti nel commit scansionato; i valori dei segreti vengono oscurati e mai conservati.
- Controlli degli errori di configurazione per Terraform e Dockerfile.
- Immagini container in un registry raggiungibile da internet, analizzate per individuare vulnerabilità, errori di configurazione e segreti.
- I pacchetti elencati nel database OpenSSF Malicious Packages vengono segnalati come critici, con la rimozione come correzione.
In arrivo
Nella roadmap, non ancora disponibile. Le date sono obiettivi, non promesse; questa pagina viene aggiornata il giorno in cui una funzionalità diventa disponibile.
- In arrivo · Q4 2026 (dicembre)Test di siti web e API. KROMSE testerà siti web e API alla ricerca di vulnerabilità, solo sui domini di cui hai verificato di avere il controllo.
- In arrivo · Q4 2026 (dicembre)Monitoraggio pianificato da te, con agenti IA. Le nuove scansioni verranno eseguite secondo una pianificazione definita da te, con agenti IA che seguono i nuovi avvisi di sicurezza, valutano quali ti riguardano, propongono correzioni e preparano il report per la tua revisione.
Domande frequenti
KROMSE testa siti web e API?
Non ancora. Oggi KROMSE non esegue test dinamici su siti web o API. Controlla ciò che c’è dietro: dipendenze, codice sorgente in 11 linguaggi, segreti committati, errori di configurazione di Terraform e Dockerfile e immagini container. I test di sicurezza di siti web e API sui domini di cui hai verificato di avere il controllo sono nella roadmap, e questa pagina cambierà quando saranno disponibili.
È legale scansionare un sito web che non è mio?
Di regola, non senza autorizzazione. La direttiva 2013/40/UE impone agli Stati membri dell’UE di punire come reato l’accesso illecito ai sistemi di informazione e l’interferenza illecita relativamente a essi, commessi intenzionalmente e senza diritto, cioè senza l’autorizzazione del proprietario o di un altro titolare di diritti, almeno nei casi che non sono di minore gravità. Le leggi nazionali aggiungono regole proprie. Testa solo sistemi di tua proprietà o per i quali hai un’autorizzazione scritta, e rispetta i termini di qualsiasi fornitore di hosting, CDN o API coinvolto.
Qual è la differenza tra DAST e penetration test?
Il DAST è di solito automatizzato: uno strumento invia molte richieste e segnala i comportamenti che corrispondono a pattern di falle noti. Un penetration test è condotto da una persona che concatena le rilevazioni, testa la logica di business e valuta l’impatto, spesso usando strumenti DAST lungo il percorso. Il test automatizzato è adatto a controlli frequenti e ripetibili; un penetration test è adatto alle release principali, alle modifiche significative e ai sistemi ad alto rischio.
Il CRA richiede test di sicurezza dell’API del mio prodotto?
Il CRA non prescrive un metodo di test. L’allegato I, parte II, richiede prove e riesami efficaci e periodici della sicurezza del prodotto, e un prodotto comprende le sue soluzioni di elaborazione dati da remoto, come un’API senza la quale la tua app non può funzionare. Scegli i metodi che la tua valutazione dei rischi giustifica e conserva il perimetro, il metodo e i risultati dei test nella tua documentazione tecnica.
Quale lista OWASP dovrei usare per le API?
Usa la OWASP API Security Top 10, la cui edizione attuale è del 2023. Si concentra sulle falle specifiche delle API, come Broken Object Level Authorization, Broken Authentication, Unrestricted Resource Consumption e Improper Inventory Management, che le liste orientate al web coprono in modo meno diretto. Usala insieme alla OWASP Top 10:2025 per il front end web.
Guide correlate
Fonti
- OWASP Top 10:2025
- OWASP API Security Top 10
- Direttiva 2013/40/UE relativa agli attacchi contro i sistemi di informazione, EUR-Lex
- Regolamento (UE) 2024/2847 (regolamento sulla ciberresilienza), EUR-Lex
- Direttiva (UE) 2022/2555 (direttiva NIS 2), EUR-Lex
- Regolamento di esecuzione (UE) 2024/2690 della Commissione, EUR-Lex