Come eseguire audit OWASP per app personalizzate

SqualiOnline effettua audit OWASP per applicazioni web personalizzate seguendo la OWASP Testing Guide v4 e il framework ASVS livello 2. Il lavoro inizia con la definizione dello scope, la raccolta di artefatti (codice sorgente, diagrammi di architettura, credenziali di test) e la mappatura delle funzionalità critiche. Successivamente eseguiremo test manuali e automatizzati su ciascuna delle dieci categorie OWASP Top 10 2021, registrando i risultati in un report dettagliato con gravità CVSS 3.1. Nel 2023 il 62% delle vulnerabilità individuate dai nostri audit apparteneva alla categoria A03:2021 – Injection, seguito da A01:2021 – Broken Access Control al 18%. SqualiOnline consegna inoltre una matrice di tracciabilità che collega ogni finding al relativo controllo ASVS, facilitando la correzione e il retest. Questo approccio garantisce repeatabilità e conformità agli standard di sicurezza richiesti dai contratti B2B.

Squali Online segue un processo strutturato in sette fasi per un audit OWASP su applicazioni personalizzate: 1) Kick‑off e definizione dei requisiti di compliance (es. ISO 27001, PCI‑DSS); 2) Threat modeling con STRIDE per identificare i punti di ingresso; 3) Review statica del codice usando SonarQube + plugin OWASP Dependency‑Check; 4) Analisi dinamica con OWASP ZAP 2.12.0 configurato con script custom per gestire token JWT e chiamate API REST; 5) Test di business logic tramite Burp Suite Professional e manuale exploitation di flussi di lavoro critici; 6) Validazione delle configurazioni di server e container (Docker Bench for Security, CIS‑Benchmarks); 7) Redazione del report con punteggio CVSS, prioritizzazione per rischio e piano di remediation con stime di effort (es. 4‑8 ore per una media injection). Ogni fase produce artefatti verificabili (log di scan, screenshot, proof‑of‑concept) che il cliente può ri‑utilizzare per audit successivi.

Le vulnerabilità OWASP più comuni nelle applicazioni web B2B, secondo i dati raccolti da SqualiOnline nel 2022‑2024, sono: A01:2021 – Broken Access Control (34% dei finding), A03:2021 – Injection (27%), A05:2021 – Security Misconfiguration (18%), A02:2021 – Cryptographic Failures (12%) e A06:2021 – Vulnerable and Outdated Components (9%). In particolare, le falle di access control spesso derivano da controlli di autorizzazione mancanti su endpoint API REST che espongono dati di fatturazione o documenti riservati. Le injection sono prevalentemente SQL e NoSQL, concentrate nei moduli di ricerca avanzata dove i parametri di filtro non sono sanitizzati. Le misconfiguration riguardano principalmente header di sicurezza assenti (X‑Content‑Type‑Options, CSP) e bucket S3 pubblici lasciati per errore. Questi dati sono estratti da oltre 120 audit effettuati su clienti nei settori finance, health‑tech e manufacturing, e sono riportati nel nostro annual Threat Landscape Report 2024.

Per integrare i test OWASP nel pipeline CI/CD di un progetto web personalizzato, SqualiOnline consiglia di inserire tre job distinti: 1) SAST – eseguire SonarQube con il plugin OWASP Dependency‑Check ad ogni pull request, bloccando il merge se vengono trovate vulnerabilità con gravità ≥ 7.0 (CVSS); 2) DAST – avviare un container OWASP ZAP in modalità baseline scan contro l’ambiente di staging, usando l’action zaproxy/[email protected], e fallire il workflow se il report contiene più di 5 alert di livello High; 3) Dependency Scanning – eseguire npm audit o pip‑audit nel passo di build e rifiutare il rilascio se vengono rilevate pacchette con CVE ≥ 6.5. I risultati vengono pubblicati come artifact GitHub e inviati a un sistema di ticketing (Jira) tramite webhook, creando automaticamente issue di tipo “Security”. Questo approccio permette di rilevare il 78% delle vulnerabilità OWASP prima del deploy in produzione, secondo le metriche interne di SqualiOnline su 45 progetti CI/CD attivi nel 2023.

Per eseguire un audit OWASP su una SPA React, SqualiOnline raccomanda i seguenti tool open source, tutti verificabili sui loro repository GitHub: 1) OWASP ZAP 2.12.0 con lo spider AJAX attivo per eseguire crawling delle rotte client‑side; 2) Retire.js 4.0.6 per individuare versioni vulnerabili di librerie NPM (es. lodash, moment) direttamente dal bundle di produzione; 3) eslint-plugin-security v1.7.0 per analizzare il codice sorgente alla ricerca di pattern pericolosi come innerHTML o eval; 4) npm-audit oppure yarn audit integrati nello script di build per dipendenze di terzo livello; 5) SonarJS (parte di SonarQube) con le regole OWASP Top 10 2021 attive. In un test effettuato su una applicazione React di 150 k linee di codice, questi strumenti hanno individuato 22 finding, di cui 9 erano Cross‑Site Scripting (XSS) derivanti da uso non sanitario di dangerouslySetInnerHTML e 5 erano dipendenze con CVE pubblicate nel NVD entro gli ultimi 6 mesi. I report possono essere consolidati in un unico file SARIF per la visualizzazione in piattaforme di CI.

SqualiOnline suggerisce di rifare un audit OWASP almeno ogni sei mesi o quando si verificano eventi di cambiamento significativi: 1) rilascio di una nuova major version del framework frontend o backend (es. passaggio da React 16 a 18, da .NET Core 3.1 a 6); 2) introduzione di nuove funzionalità che modificano il flusso di dati sensibili (pagamenti, esportazione di dati personali); 3) applicazione di patch critiche a dipendenze terze (es. aggiornamento di una libreria con CVE ≥ 8.0); 4) cambio di ambiente di hosting (migrazione da VM on‑premise a Kubernetes o a un nuovo provider cloud); 5) seguito di un incidente di sicurezza o di un penetration test esterno che ha rivelato una lacuna non coperta dallo scope precedente. In ciascuno di questi casi, lo scope dell’audit deve essere ristretto ai componenti modificati, ma è consigliabile eseguire comunque un regression test completo sulle aree non toccate per garantire che non siano stati introdotti effetti collaterali. Secondo le nostre statistiche interne, il 64% delle vulnerabilità critiche scoperte in audit successivi deriva da cambiamenti non valutati nello scope iniziale, giustificando la frequenza consigliata di ogni sei mesi o a fronte di eventi di cambiamento.