Una checklist dei requisiti di sicurezza per applicazioni web traduce la sicurezza in un ambito contrattuale: ogni requisito ha un responsabile, una verifica con esito superato o non superato, le prove richieste e un termine per porre rimedio. Inserisca questo prospetto accanto all'elenco delle funzionalità prima di avviare lo sviluppo.
Il controllo degli accessi inadeguato resta al primo posto nella OWASP Top 10:2025. Una scansione può comunque non rilevare la regola di business che stabilisce se un cliente possa aprire la fattura di un altro cliente.
Chi acquista di solito sa quali dati devono essere protetti, ma il contratto può descrivere le schermate con molti più dettagli rispetto ai test di sicurezza. Questa guida offre un prospetto pronto per il contratto, basato su OWASP ASVS 5.0, insieme alle prove richieste per l'accettazione. Assegna inoltre gli obblighi che proseguono dopo la consegna.
- Indichi OWASP ASVS 5.0 con versione e livello. La OWASP Top 10 illustra i rischi, mentre ASVS fornisce requisiti che producono un esito superato o non superato.
- Assegni quattro campi a ogni requisito: responsabile, test di accettazione, prova e termine per porre rimedio.
- Verifichi l'autorizzazione con due utenti o tenant. Un accesso riuscito non dice nulla sull'accesso ai dati, alle esportazioni, ai file o alle azioni amministrative di un altro cliente.
- Includa le prove nella consegna. Chi acquista deve ricevere la matrice dei requisiti, i risultati dei test, le eccezioni note, le note di deployment e la prova del ripristino.
- Mantenga la manutenzione nell'ambito del contratto. Le patch delle dipendenze, l'assistenza per gli incidenti, il trasferimento delle credenziali e i tempi di risposta decorrono dalla messa in esercizio dell'applicazione.
Una promessa di sicurezza richiede un test di accettazione
OWASP descrive la propria Top 10 come un documento di sensibilizzazione e raccomanda l'Application Security Verification Standard per requisiti verificabili di sicurezza delle applicazioni. ASVS 5.0 comprende circa 350 requisiti suddivisi in 17 capitoli, ciascuno pensato per produrre un esito superato o non superato.
ASVS si presta anche all'acquisto di software su misura. Chi acquista può indicare un livello, selezionare i requisiti pertinenti e chiedere al fornitore di provare la conformità mediante riferimenti con versione, come `v5.0.0-1.2.5`. Questa formulazione è adatta a un contratto perché il riferimento resta valido anche se cambiano il fornitore o il soggetto incaricato dei test.
Un progetto webvise realizzato in sei settimane per un servizio immobiliare tedesco comprendeva una procedura finanziaria di acquisizione dati in 10 passaggi, la generazione automatica di PDF e una dashboard amministrativa, con un obiettivo di evasione inferiore a 24 ore. Questo flusso solleva domande precise sulla sicurezza: chi può leggere una richiesta, modificarne lo stato, generare il PDF, scaricarlo e consultare la cronologia di audit? Una clausola come `autenticazione inclusa` lascia aperta ciascuna di queste decisioni.
Se la Sua applicazione contiene un flusso privato di questo tipo, il servizio webvise per applicazioni su misura comprende autenticazione, autorizzazione, progettazione delle API, CI/CD, monitoraggio e test dei flussi critici concordati. Il prospetto di sicurezza stabilisce quali rischi devono coprire questi elementi della consegna.
Scelga un livello ASVS prima del preventivo
ASVS prevede tre livelli di approfondimento crescente. OWASP cita un prodotto in fase iniziale con pochi dati sensibili come possibile caso di Level 1, mentre per una banca online può essere difficile giustificare un livello inferiore al Level 3. Chi acquista e il fornitore scelgono il livello in base ai dati dell'applicazione, agli utenti, all'impatto sul business e ai probabili autori degli attacchi.
| Livello ASVS | Applicazione pratica per chi acquista | Indicazione contrattuale |
|---|---|---|
| Level 1 | Prodotto in fase iniziale con pochi dati sensibili e un modello di minaccia circoscritto | Applicare ogni requisito L1 pertinente e documentare i capitoli esclusi |
| Level 2 | B2B SaaS, portali clienti, fatturazione, dati privati o interruzioni rilevanti dell'attività | Applicare i requisiti L2 pertinenti, indicare i flussi sensibili e richiedere prove tracciabili |
| Level 3 | Servizi bancari, sanità, amministrazione critica o sistemi in cui una violazione potrebbe causare danni gravi | Concordare l'ambito L3 con uno specialista della sicurezza e definire una verifica indipendente |
La tabella è una guida al rischio per chi acquista, poiché OWASP lascia a ogni organizzazione la scelta finale del livello. Adatti anche i capitoli. Un'applicazione priva di OAuth, WebSockets, GraphQL o interfaccia web può escludere le relative sezioni, purché le esclusioni compaiano nel prospetto contrattuale.
Indichi nel contratto la versione esatta di ASVS. `ASVS Level 2` può cambiare significato dopo una release principale, mentre `OWASP ASVS v5.0.0, requisiti L2 selezionati nell'Appendice A` offre a entrambe le parti un riferimento stabile per i test.
Copi il prospetto di sicurezza con 12 requisiti
Utilizzi il seguente prospetto come allegato sulla sicurezza a un brief o a un capitolato. Ogni riga richiede un responsabile nominato, il test finale, le prove consegnate a chi acquista e il tempo concesso per correggere un test non superato.
| Area | Requisito contrattuale | Prova di accettazione |
|---|---|---|
| 1. Mappa dei rischi e dei dati | Elencare dati sensibili, attori, sistemi, confini di fiducia, conservazione e usi vietati | Nota approvata sul flusso dei dati e registro dei rischi |
| 2. Autenticazione e sessioni | Definire le regole per accesso, reimpostazione, disconnessione, scadenza della sessione, MFA e recupero dell'account | Test automatici dei flussi e registro della configurazione |
| 3. Autorizzazione | Definire ogni ruolo, risorsa protetta, azione consentita e confine tra tenant | Matrice degli accessi e test orizzontali, verticali e tra tenant |
| 4. Gestione di input e file | Convalidare sul server tutti gli input provenienti da client, API, webhook, query e caricamenti | Test per tipi non validi, limiti di dimensione, input non corretti e file non sicuri |
| 5. Segreti e crittografia | Tenere i segreti fuori dal codice sorgente e definire le regole di cifratura, rotazione e accesso | Inventario dei segreti, configurazione dell'archiviazione e procedura di rotazione |
| 6. Dipendenze e supply chain | Tracciare le dipendenze dirette e transitive, sottoporle a scansione e fissare i tempi di risposta per le patch | Lockfile, inventario delle dipendenze, rapporto di scansione e registro delle eccezioni |
| 7. Servizi esterni | Definire autenticazione, ambiti, timeout, nuovi tentativi, convalida e comportamento in caso di errore per ogni integrazione | Test di integrazione ed elenco dei titolari delle credenziali |
| 8. Log e avvisi | Registrare gli eventi di sicurezza senza payload sensibili e inoltrare gli avvisi operativi a un responsabile nominato | Catalogo degli eventi, impostazione di conservazione e test di attivazione dell'avviso |
| 9. Comportamento in caso di errore | Definire un comportamento sicuro per richieste non riuscite, scritture parziali, servizi non disponibili e stati imprevisti | Test dei percorsi di errore che dimostrino il rollback o un arresto sicuro |
| 10. Backup, ripristino ed eliminazione | Stabilire la frequenza dei backup, l'obiettivo di ripristino, la conservazione, l'esportazione e le regole di eliminazione verificata | Risultato del test di ripristino e test di eliminazione |
| 11. Pipeline di build e release | Proteggere i branch, limitare l'accesso alla produzione, eseguire la scansione delle modifiche e registrare i deployment | Configurazione CI/CD, elenco degli accessi e cronologia delle release |
| 12. Consegna e interventi correttivi | Trasferire codice sorgente, infrastruttura, credenziali, problemi noti, obiettivi di risposta e obblighi di manutenzione | Elenco di consegna firmato e tabella degli interventi correttivi basata sulla gravità |
La riga sulle dipendenze ha un peso concreto. Il 14 settembre 2025, il worm Shai-Hulud è entrato in npm tramite account di maintainer compromessi e script post-install dannosi. OWASP registra più di 500 versioni di pacchetti interessate prima che npm interrompesse la diffusione del worm.
Un fornitore non può garantire ogni pacchetto per sempre. Il contratto può richiedere un inventario alla consegna, verifiche automatiche durante lo sviluppo, eccezioni scritte e un tempo di risposta definito per le nuove criticità. Questi elementi assegnano a qualcuno il rischio del codice di terze parti, invece di lasciarlo come presupposto invisibile.
Aggiunga questo prospetto alla sezione tecnica del brief per un'agenzia web prima di chiedere un preventivo. Il fornitore potrà così quantificare il costo delle prove richieste e segnalare i controlli che richiedono uno specialista della sicurezza indipendente.
Riscriva ogni clausola con un esito superato o non superato
ASVS limita i propri requisiti a risultati verificabili. Applichi la stessa regola al contratto: un'altra persona qualificata deve giungere allo stesso risultato dopo aver letto il criterio ed eseguito il test indicato.
| Requisito vago | Criterio di accettazione con esito superato o non superato | Prova |
|---|---|---|
| Usare un accesso sicuro | Le sessioni scadute, revocate e mancanti ricevono 401; cinque tentativi non riusciti attivano il controllo concordato | Risultati dei test automatici di autenticazione |
| Mantenere privati i dati dei clienti | L'utente B non può leggere, modificare, eliminare o esportare i dati creati nel tenant dell'utente A | Test delle richieste tra due tenant con risposta 403 o 404 |
| Proteggere le funzioni amministrative | Ogni route amministrativa respinge sul server le richieste anonime e quelle degli utenti standard | Matrice dei ruoli e risultati dei test a livello di route |
| Convalidare i caricamenti | Il server rifiuta tipi non consentiti, dati MIME non corrispondenti, file troppo grandi e nomi di file non sicuri | Set di test per i caricamenti e ispezione dei file archiviati |
| Monitorare gli attacchi | Una raffica di prova di accessi non riusciti genera un avviso per il responsabile nominato entro il tempo concordato | Registrazione dell'evento, dell'avviso e della ricezione con data e ora |
| Mantenere sicure le dipendenze | La consegna non contiene criticità irrisolte al di fuori del registro delle eccezioni firmato | Rapporto datato sulle dipendenze ed eccezioni approvate |
Next.js rende concreto questo principio. La sua guida alla sicurezza dei dati, aggiornata il 27 febbraio 2026, afferma che ogni Server Action esportata crea un endpoint HTTP pubblico e richiede gli stessi controlli di autorizzazione di un'API. Utilizzi come prova un test automatico delle richieste. Nascondere un pulsante dimostra soltanto lo stato dell'interfaccia.
L'autorizzazione richiede più test perché una verifica dell'accesso copre soltanto l'identità. Ripeta le azioni protette come altro utente con lo stesso ruolo, con un ruolo inferiore, con un tenant diverso, con una sessione scaduta e senza sessione. Applichi questa matrice a letture, scritture, esportazioni, file, processi in background e strumenti amministrativi.
Richieda le prove prima dell'accettazione
L'OWASP Secure Software Contract Annex definisce le prove finali come un pacchetto di certificazione. Secondo OWASP, per alcuni progetti possono bastare una breve valutazione dei rischi, poche pagine di requisiti, una nota sulla progettazione della sicurezza, un piano di test e i risultati.
- Nota sui rischi e sul flusso dei dati: attori, campi sensibili, sistemi, confini di fiducia, conservazione e responsabile che ha approvato ogni decisione.
- Matrice dei requisiti con versione: ID ASVS 5.0 selezionati, applicabilità, responsabile, stato, riferimento al test ed eventuali eccezioni.
- Matrice delle autorizzazioni: attore, risorsa, azione, risultato atteso ed esito del test automatico per i flussi protetti.
- Registro delle dipendenze: inventario diretto e transitivo, scansione datata, criticità irrisolte ed eccezioni firmate.
- Nota sul deployment: accesso alla produzione, posizione dei segreti, impostazioni di sicurezza, domini, servizi esterni e procedura di rollback.
- Prova di ripristino: un test di ripristino completato con data, durata, risultato ed eventuali lacune rilevate.
- Prova di monitoraggio: un evento di sicurezza attivato, l'avviso generato, il destinatario e l'ora di ricezione.
Gli scanner automatici coprono soltanto una parte di questo pacchetto. OWASP avverte che la Top 10 non può costituire la copertura completa di uno strumento, poiché la progettazione non sicura, l'autorizzazione di business e l'efficacia degli avvisi richiedono una revisione o una verifica dal vivo. Si rivolga a uno specialista per test indipendenti quando l'applicazione gestisce dati regolamentati, movimenti di denaro, cartelle cliniche o attività amministrative ad alto impatto.
La clausola di accettazione deve indicare chi esamina il pacchetto e quali criticità bloccano la consegna. Una regola praticabile blocca l'accettazione in presenza di criticità irrisolte di gravità critica o alta, mentre un'eccezione firmata può rinviare una criticità minore assegnandole un responsabile e una scadenza. Un avvocato qualificato deve esaminare la formulazione definitiva del contratto in base alla giurisdizione applicabile.
Definisca gli obblighi di sicurezza dopo la consegna
La consegna chiude la fase di sviluppo e apre quella operativa. Nuove criticità nelle dipendenze, certificati scaduti, credenziali esposte, cambiamenti nel personale, schemi di abuso e integrazioni non riuscite emergono secondo tempi propri. Il contratto deve assegnare un responsabile a ciascuno di questi eventi.
| Clausola successiva alla consegna | Decisione da registrare |
|---|---|
| Canale di segnalazione | Dove inviare le segnalazioni di sicurezza, chi le riceve e come confermarne la ricezione |
| Gravità e risposta | Come stabilire la gravità e l'obiettivo di risposta o correzione per ogni fascia |
| Manutenzione delle dipendenze | Chi esamina gli avvisi, applica gli aggiornamenti, verifica la compatibilità e distribuisce le patch |
| Assistenza per gli incidenti | Disponibilità, tariffe, conservazione delle prove, comunicazione e autorità decisionale |
| Titolarità delle credenziali | Quali account appartengono a chi acquista e quando ruotare chiavi, domini e token |
| Fine del servizio | Esportazione del codice sorgente, trasferimento dell'infrastruttura, restituzione dei dati, eliminazione verificata e revoca degli accessi |
La proprietà del codice sorgente è utile soltanto se chi acquista può anche eseguire l'applicazione. Richieda il repository, la configurazione CI/CD, le impostazioni dell'infrastruttura, l'inventario degli ambienti, la cronologia delle migrazioni del database, l'accesso al monitoraggio e una procedura di deployment verificata. Nella consegna di applicazioni su misura, webvise include la proprietà del codice sorgente, la documentazione dei flussi critici, CI/CD, monitoraggio e infrastruttura operativa.
webvise può trasformare questa checklist in un prospetto di sicurezza con un ambito definito per una nuova applicazione su misura, includendo nel progetto il livello ASVS pertinente, le prove e le clausole di consegna. Invii a webvise il flusso di lavoro e i tipi di dati prima che il preventivo venga fissato.
Le pratiche di webvise sono allineate agli standard ISO 27001 e ISO 42001.