Cos'è la codifica sicura?

La codifica sicura, nota anche come programmazione sicura, è la pratica di scrivere codice sorgente in grado di difendersi da attacchi informatici da attori delle minacce. L'integrazione della sicurezza nel codice aiuta a limitare le vulnerabilità, creando un software sufficientemente robusto e resiliente da resistere alle minacce informatiche.

La programmazione sicura è una parte vitale del ciclo di vita dello sviluppo del software sicuro (SSDLC). A differenza del tradizionale SDLC, in cui la sicurezza entra in gioco solo durante la fase di test, l'SSDLC integra la cybersecurity in ogni fase del processo di sviluppo software. La sicurezza del codice non è solo un aspetto secondario, un componente aggiuntivo opzionale o un aspetto separato, ma un elemento essenziale della creazione di software sicuro.

La codifica sicura rientra anche nell'ambito più ampio della sicurezza delle applicazioni. Mentre la programmazione sicura si concentra sull'integrazione della cybersecurity nel codice, la sicurezza delle applicazioni copre un ampio spettro di misure di sicurezza (dalle tutele hardware alle difese basate su software) e copre l'intero SDLC.

Lo sfruttamento delle vulnerabilità è diventato la principale causa di attacchi, secondo l'X-Force Threat Intelligence Index 2026 di IBM. Passando a un approccio più proattivo e preventivo, come la codifica sicura, si possono cogliere le minacce prima ancora che si aggravino.

La programmazione sicura offre questi vantaggi:

• Efficienza in termini di costi: è meno costoso correggere i difetti di sicurezza prima dell'implementazione che dopo il rilascio.

• Sicurezza dei dati: le protezioni per i dati sensibili sono applicate a livello di codice sorgente, a sostegno della conformità alle normative sulla protezione dei dati.

• Rilevamento e prevenzione precoci: le vulnerabilità vengono rilevate ed eliminate durante lo sviluppo, evitando che si propaghino alla produzione.

• Risparmio di tempo e fatica: il codice sicuro può contribuire a evitare il notevole dispendio di tempo e fatica associato alla gestione degli incidenti e alla correzione dei problemi sui sistemi in produzione.

Le vulnerabilità di sicurezza nel codice di solito derivano da errori di progettazione e architettura del software, errori di configurazione o programmazione, solo per citarne alcuni. Gli attori malevoli spesso utilizzano queste vulnerabilità come punti di ingresso per gli attacchi.

Ecco alcune vulnerabilità tipiche che la programmazione sicura mira ad risolvere, basandosi sull'elenco dei rischi per la sicurezza delle applicazioni web del Open Worldwide Application Security Project (OWASP):

• Errori di autenticazione

• Controlli di accesso danneggiati

• Errori crittografici

• Attacchi di injection

• Progettazione non sicura

• Registrazione e segnalazione degli errori

• Errata configurazione della sicurezza

• Errori di integrità del software o dei dati

I criminali informatici sfruttano le vulnerabilità dei meccanismi di autenticazione per rubare le credenziali degli utenti e condurre attività dannose. Gli errori di autenticazione includono politiche di password deboli, mancanza di metodi di autenticazione robusti, gestione impropria delle sessioni e protezione insufficiente da schemi di cracking delle password come attacchi di forza bruta che trovano le password corrette attraverso tentativi ed errori o riempimento di credenziali per ottenere l'accesso agli account di un utente attraverso il nome utente violato e coppie di password.

I controlli di accesso stabiliscono chi può accedere a dati o risorse e quali azioni possono intraprendere. Controlli infranti o applicati in modo errato possono portare ad accessi non autorizzati e all'abuso di privilegi. Le minacce possono comportare la modifica delle richieste API e dei parametri URL per bypassare i controlli di controllo degli accessi o riferimenti diretti non sicuri a oggetti che permettono di fare riferimento direttamente a dati o risorse usando identificatori unici senza verificare le autorizzazioni.

Le falle nelle metodologie crittografiche possono esporre dati sensibili e causare violazioni dei dati. I guasti crittografici comprendono algoritmi di crittografia obsoleti o deboli, protocolli di gestione principale scadenti, l'uso di chiavi codificate rigidamente e la trasmissione o la memorizzazione dei dati senza una crittografia adeguata.

Gli attacchi di tipo injection sono una delle tipologie più comuni di vulnerabilità di sicurezza. Input malevoli (codici, comandi, query o script) vengono inseriti in un programma o pagina web per lanciare malware, modificare dati o sottrarre informazioni private, tra altre azioni nefaste. Il cross-site scripting, la falsificazione delle richieste cross-site e la falsificazione delle richieste lato server sono alcuni degli attacchi di injection più diffusi.

Il cross-site scripting (XSS) distribuisce codice o script non attendibili su siti web affidabili, che vengono poi eseguiti da utenti ignari. Di solito si verifica quando un'applicazione non riesce a evadere, filtrare, sanificare o convalidare i dati forniti dall'utente.

La falsificazione delle richieste tra siti (CSRF o XSRF) invia richieste non autorizzate a un sito web da un utente autenticato. Utilizza al meglio la fiducia che un sito ripone nel browser web di un utente autenticato, utilizzando link o script che ingannano il browser inducendolo a inviare richieste dannose al sito target.

La falsificazione delle richieste lato server (SSRF) manipola gli URL inviati a un server. Quando il server raccoglie la richiesta manipolata senza prima convalidare l'URL, tale richiesta può essere utilizzata per connettersi a servizi interni come i database o leggere file, configurazione del server e altri metadati.

Una progettazione non sicura riguarda vulnerabilità causate da difetti nella logica di business o nell'architettura delle applicazioni. Si verifica prima nell'SDLC durante la fase di pianificazione, quando si definiscono i requisiti e si mappa il blueprint di sistema. Fattori come la mancanza di valutazione del rischio, l'uso limitato di modelli di progettazione e architetture di riferimento sicuri e la modellazione delle minacce a livello minimo per analizzare sistematicamente le potenziali vulnerabilità di sicurezza nell'architettura pianificata possono tutti contribuire a una progettazione non sicura.

Avvisi e registri inadeguati o inefficaci possono comportare attacchi e violazioni non rilevati, consentendo agli autori delle minacce di causare gravi danni. Alcuni casi di errori di registrazione e avviso comportano eventi critici non registrati o registrati in modo incoerente, archiviazione di log non sicura che potrebbe essere soggetta a manomissioni o accessi non autorizzati, avvisi insufficienti per attacchi attivi in tempo reale o quasi, messaggi di log poco chiari o privi di dettagli o contesto e log che contengono dati sensibili senza mascherarli o cancellarli.

Questa vulnerabilità si verifica quando le impostazioni di sicurezza dello stack dell'applicazione, inclusi cloud service, database, framework, librerie, sistemi operativi e server web, non sono configurate correttamente. L'errata configurazione della sicurezza comprende aggiornamenti di sicurezza disabilitati, autorizzazioni troppo ampie, credenziali predefinite invariate e funzionalità non necessarie lasciate abilitate.

Questi errori sono legati alla mancanza di garanzie rispetto all'accettazione o all'elaborazione di dati non validi o non affidabili provenienti da fonti esterne. Gli esempi comprendono l'applicazione automatica di aggiornamenti software senza convalidarne l'integrità, l'uso di fonti non affidabili per dipendenze come librerie e plugin di terze parti, e pipeline CI/CD che estraggono codice o altri artefatti di sviluppo software senza verificarli.

Alcune tecnologie di AI generativa possono aiutare con la programmazione sicura. Ad esempio, piattaforme di codifica agentic AI come Claude Code e IBM Bob possono mettere in luce le vulnerabilità e suggerire correzioni per codice non sicuro in tempo reale. Gli strumenti di generazione di codice AI possono inoltre contribuire a rifattorizzare il codice per migliorare la sicurezza.

Sebbene possano automatizzare e velocizzare lo sviluppo software, gli assistenti di codifica AI hanno ancora bisogno di una guida per generare codice sicuro. I programmatori devono fornire dei prompt chiari in grado di specificare non solo la funzionalità ma anche i requisiti di sicurezza. Ad esempio, un prompt generico come "crea una funzione di accesso" può essere esteso a "crea una funzione di accesso che verifichi gli input dell'utente in base al formato e alla lunghezza previsti" per includere istruzioni di codifica sicura. La guida della Open Source Security Foundation contiene istruzioni di esempio per aiutare gli assistenti AI a tenere conto della sicurezza del codice.

I team di ingegneria del software possono inoltre fornire un contesto che indirizzi l'AI generativa verso la produzione di codice più sicuro. La retrieval-augmented generation (RAG) collega gli strumenti di sviluppo basati sull'AI con gli standard interni di codifica sicura. Per i team senza linee guida definite, le regole di sicurezza AI di Secure Code Warrior rappresentano un punto di partenza per un codice generato dall'AI più sicuro.

Come gli assistenti AI, gli agenti di codifica AI traggono beneficio dalla guida. Project CodeGuard offre un regolamento e un framework di competenze che integra pratiche di codifica sicure direttamente nei workflow agentici. Un agente di codifica AI può utilizzare queste regole e competenze durante la fase di pianificazione come parte integrante dei suoi obiettivi e durante la fase di esecuzione mentre scrive il codice.

Il codice prodotto dall'intelligenza artificiale stessa può introdurre delle vulnerabilità, quindi la decisione finale su accuratezza e sicurezza ricade ancora sui programmatori umani. Le misure di AI generativa devono inoltre essere combinate con le best practice di codifica sicura per costruire molteplici livelli di protezione.

Le best practice nella codifica sicura comprendono varie strategie di programmazione difensive per rafforzare la sicurezza del software. Le aziende potrebbero essere preoccupate di bilanciare la codifica sicura con la velocità di consegna. Tuttavia, molte di queste pratiche integrano la sicurezza nel codice senza sacrificare la consegna rapida, come la fusione della sicurezza nella fase di progettazione, l'istituzione di linee guida di codifica sicura, la formazione degli sviluppatori in modo che siano attrezzati per identificare e correggere le vulnerabilità di sicurezza durante la programmazione, e l'automatizzazione dell'analisi e dei test del codice per individuare vulnerabilità.

Anche se è impossibile menzionare tutte le best practice di codifica sicura esistenti, questa lista rappresenta un punto di partenza, e combinare queste pratiche può migliorare il livello di sicurezza di un'organizzazione:

• Seguire standard di codifica sicuri

• Integrare la sicurezza nella progettazione

• Convalidare e sanificare gli input e codificare gli output

• Implementare protocolli crittografici robusti

• Autenticare e autorizzare

• Stabilire meccanismi robusti di registrazione e gestione sicura degli errori

• Effettuare test di sicurezza approfonditi

• Aggiungere la sicurezza come parte integrante delle revisioni del codice

Questi standard rappresentano delle guide fondamentali per integrare in modo efficace le tecniche di codifica sicura nei workflow di sviluppo esistenti. Forniscono una base condivisa per la programmazione sicura tra progetti software.

La guida per gli sviluppatori OWASP è un riferimento per i programmatori, per aiutarli a navigare e a creare codice sorgente sicuro. La guida delinea le pratiche di codifica sicura indipendenti dalla tecnologia, con i principali punti di sicurezza del codice evidenziati nelle liste di controllo migrate dall' OWASP Secure Coding Practices Quick Reference Guide archiviata.

L'OWASP fornisce anche una serie di schede informative per implementare principi di codifica sicura e contrastare un'ampia gamma di vulnerabilità del codice.

Creati dall'Istituto di Ingegneria del Software della Carnegie Mellon University, gli standard di codifica SEI CERT  offrono indicazioni per una programmazione sicura nei linguaggi di programmazione Android, C, C++, Java e Perl. Gli standard contengono regole, raccomandazioni ed esempi di codice conforme e non conforme. Le norme e le raccomandazioni sono accompagnate da valutazioni del rischio classificate in base a gravità, probabilità e costi di correzione, per aiutare i team di ingegneri del software a dare priorità ai loro sforzi.

Accanto al tuo framework di cybersecurity per la la sicurezza delle informazioni e la gestione del rischio di cybersecurity, il National Institute of Standards and Technology (NIST) ha anche pubblicato il suo Secure Software Development Framework. Il framework è costituito da pratiche di sviluppo software sicure di alto livello e basate sui risultati, che lo rendono un complemento ideale agli standard più tecnici di OWASP e SEI CERT.

L'integrazione di una progettazione sicura nel blueprint di un sistema è in linea con l'approccio "shift left" di spostare la sicurezza nelle prime fasi del processo di sviluppo software. Prende in considerazione i metodi per rendere il software sicuro ancor prima che venga scritta la prima riga di codice.

Le valutazioni complete dei rischi e la modellazione delle minacce possono aiutare a far emergere potenziali vulnerabilità di sicurezza nell'architettura software. La fase di progettazione sicura deve prevedere anche il coinvolgimento dei team di sicurezza per una collaborazione pratica e una guida sui requisiti di sicurezza e su come gestirli a livello di codice sorgente.

Per maggiori informazioni sull'integrazione della sicurezza nel design, i team possono consultare le schede informative di OWASP sulla progettazione sicura di prodotti e modellazione delle minacce e il suo framework Secure by Design.

Un principio fondamentale della codifica sicura è non fidarsi mai di alcun input, come dimostrato dagli attacchi a iniezione. La validazione e la sanificazione lato server aiutano a garantire che gli input non presentino rischi di sicurezza ancor prima di essere elaborati.

I team di ingegneri del software possono inserire tutta la logica di convalida e sanificazione in un file o in un luogo centrale sicuro per mantenere la coerenza e consentire accesso e aggiornamenti rapidi e semplici. Possono anche utilizzare i moduli di convalida e sanificazione integrati nei linguaggi e nei framework di programmazione, ma devono essere aggiornati regolarmente per affrontare le vulnerabilità appena scoperte.

La validazione dell'input verifica che il tipo di dato, il formato, la lunghezza, la portata, la dimensione e altri vincoli siano corretti. Questo può comportare l'abbinamento degli input a pattern approvati o il confronto con un insieme consentito di caratteri o valori.

La sanificazione degli input ne comporta la pulizia e la conversione in una forma sicura. Deve essere adattato a un linguaggio di programmazione o a un framework.

In HTML, ad esempio, l'escape di caratteri speciali come &, <, >, “ e ‘ può aiutare a prevenire l'XSS. Librerie come DOMPurify possono aiutare nella sanificazione dell'HTML.

Per i database, l'accoppiamento di query parametrizzate con istruzioni preparate può aiutare a prevenire gli attacchi di iniezione di SQL, poiché gli input vengono trattati come dati anziché come codice SQL che può essere eseguito inavvertitamente. Le query parametrizzate definiscono prima tutto il codice SQL, con segnaposto per input o parametri, quindi passano ogni parametro alla query in un secondo momento. Le istruzioni preparate sono istruzioni SQL precompilate, ovvero che i comandi SQL iniettati non possono cambiare l'intento di una query o il modo in cui viene eseguita.

La codifica in output permette di visualizzare i dati in modo sicuro come testo, così da non essere interpretati come codice. Molti framework includono la protezione predefinita per l'output in uscita o funzioni automatiche di codifica ed escape. L'OWASP Java Encoder supporta la codifica contestuale di output per diversi contesti, come inserire variabili in un URL, il CSS inline o JavaScript inline, oltre a inserire variabili in un valore di attributo HTML, proprietà CSS o tra due tag HTML.

Se applicata correttamente, la crittografia salvaguarda la riservatezza, l'integrità e la disponibilità delle informazioni.

I programmatori devono utilizzare algoritmi attuali e robusti per criptare i dati in transito e quelli inattivi. L'AES è considerato il gold standard per la crittografia simmetrica, con modalità autenticate e una chiave a 256 bit che forniscono un elevato livello di sicurezza. Per la crittografia asimmetrica, un ECC con una curva sicura o un RSA con padding casuale abilitato e almeno una chiave a 2048 bit offrono una sicurezza robusta.

Per proteggere le password, è necessario applicare algoritmi di hashing e aggiungere una salt (una stringa distinta generata in modo casuale) alla password come parte integrante del processo di hashing. Un algoritmo di hashing è una funzione matematica unidirezionale che converte i dati in un valore univoco, più breve e a lunghezza fissa, che non può essere decodificato o invertito. Gli algoritmi di hashing moderni includono Argon2id e scrypt.

Invece di crearne una propria, gli sviluppatori devono adottare implementazioni affidabili, supportate e mantenute di librerie crittografiche come Bouncy Castle, Libsodium, OpenSSL e Tink.

Le chiavi non devono essere codificate rigidamente nel codice sorgente, registrate nei sistemi di controllo versioni, memorizzate nelle variabili dell'ambiente o esposte nei log. Le soluzioni e le tecnologie di gestione delle chiavi possono contribuire ad automatizzare il ciclo di vita della gestione delle chiavi, dalla generazione, distribuzione e stoccaggio all'uso, rotazione, revoca e distruzione.

Quando si tratta di protezione del livello di trasporto, i team di ingegneria del software devono utilizzare protocolli come Hypertext Transfer Protocol Secure (HTTPS) o HTTP Strict Transport Security (HSTS) e l'ultima versione di TLS. La cache dei dati sensibili deve essere disattivata e lo storage non necessario dei dati sensibili deve essere evitato.

L'autenticazione e l'autorizzazione sono pratiche di codifica sicura cruciali per verificare l'identità di un'entità e assicurarsi che abbia il livello di accesso corretto.

L'autenticazione a più fattori (MFA) è una delle migliori difese contro gli attacchi legati alle password. Altri meccanismi includono la limitazione degli accessi per impedire agli hacker di indovinare le password troppe volte e il blocco degli account per interrompere i tentativi di accesso per un certo periodo di tempo dopo una serie di accessi non riusciti.

Per l'autenticazione senza password, gli sviluppatori possono considerare protocolli come OpenID Connect (OIDC) e Security Assertion Markup Language (SAML). Gli standard aperti FIDO eFIDO2 facilitano l'autenticazione senza password tramite passkey e possono essere utilizzati per l'autenticazione di applicazioni, servizi online e siti web.

Una volta stabilita una sessione autenticata, questa deve essere mantenuta tramite ID di sessione o token sicuri. Gli ID di sessione devono essere generati utilizzando un forte generatore di numeri pseudorandom sicuro dal punto di vista crittografico. Come per qualsiasi altro input utente, gli ID di sessione o i token devono essere validati prima dell'elaborazione, con i valori non validi filtrati.

L'impostazione del timeout di scadenza per ogni sessione limita la durata in cui gli attori malintenzionati possono dirottare le sessioni attive e lanciare attacchi. I team di ingegneria del software possono utilizzare le funzionalità integrate di gestione delle sessioni fornite dai framework di sviluppo web.

I programmatori possono utilizzare protocolli di autorizzazione come OAuth, che funzionano in tandem con il protocollo di autenticazione OIDC. In termini di controllo degli accessi, il controllo degli accessi basato sui ruoli (RBAC) è un modello popolare, in cui agli utenti viene concesso l'accesso in base al ruolo predefinito. Altre opzioni che possono essere più robuste e supportare autorizzazioni più dettagliate riguardano il controllo degli accessi basato sugli attributi (ABAC) e il controllo degli accessi basato sulle relazioni (ReBAC). ABAC analizza gli attributi delle azioni, degli oggetti e degli utenti, come il nome dell'utente, il tipo di risorsa e l'ora del giorno, per determinare se l'accesso sarà concesso. ReBAC concede l'accesso in base alle relazioni tra le risorse.

Anche con i protocolli e i modelli di controllo degli accessi in atto, le autorizzazioni devono comunque essere convalidate su ogni richiesta e i controlli di controllo degli accessi devono essere effettuati per ogni oggetto a cui un'entità tenta di accedere. Negare l'accesso di default e applicare il minor privilegio sono anche principi essenziali di codifica sicura quando si tratta di autorizzazione.

I registri e i messaggi di errore possono essere ricche fonti di informazioni per aiutare i malintenzionati a ideare gli attacchi. Questo significa che sia i log che gli errori devono essere gestiti con attenzione.

Gli errori applicativi, gli eventi di sistema relativi a modifiche di configurazione e ad azioni amministrative o privilegiate, e gli eventi di guasto nelle aree di autenticazione, autorizzazione, validazione degli input e gestione delle sessioni devono essere tutti registrati poiché possono indicare tentativi di violazione. Devono essere incluse informazioni sufficienti, come i dati utente (identità, ruoli e permessi) e il contesto dell'errore o dell'evento (target, azione ed esito), per facilitare l'analisi e il debug.

I log devono essere scritti su supporti di sola lettura e memorizzati in una posizione sicura con accesso limitato e rilevamento delle manomissioni integrato. Se i log devono essere inviati ad altri sistemi, è necessario utilizzare un protocollo di trasmissione sicuro.

I dati sensibili non devono essere registrati e devono essere analizzati o eliminati dai registri. Qualsiasi altra informazione ritenuta critica, come stringhe di connessione al database, percorsi di file, nomi e indirizzi di rete interni, ID di sessione o token, deve essere criptata, sottoposta a hashing o mascherata.

Le librerie di logging devono essere aggiornate periodicamente per assicurarsi che le vulnerabilità di sicurezza vengano corrette con patch, come dimostrato dalla vulnerabilità Log4Shell, che interessa la libreria di logging open-source Log4j ampiamente diffusa e permette agli hacker di eseguire praticamente qualsiasi codice vogliano sui sistemi interessati.

La gestione degli errori va di pari passo con la registrazione, poiché le informazioni sugli errori appaiono tipicamente nei registri. E gli errori non gestiti possono fungere da porta d'ingresso per gli attori della minaccia.

Gli sviluppatori possono considerare la creazione di un gestore globale di errori che restituisca una risposta generica o un codice di errore per errori imprevisti e poi registri ulteriori dettagli sull'errore lato server. In questo modo si evita di far trapelare informazioni agli hacker, gestendo gli errori in modo sicuro e fornendo ai programmatori i risultati necessari per ulteriori indagini.

Tutte le misure di sicurezza incorporate nel codice sorgente devono essere verificate. I team di QA e sviluppo possono fare riferimento alla Web Security Testing Guide e all' Application Security Verification Standard di OWASP come base per testare la sicurezza del codice. Anche gli strumenti automatizzati possono assistere nel processo.

I test statici di sicurezza delle applicazioni (SAST) applicano regole predefinite per individuare modelli nel codice che indicano probabili vulnerabilità. SAST viene talvolta definito test "white box", mentre gli strumenti SAST sono anche noti come analizzatori di codice statici perché analizzano il codice senza la necessità di eseguire l'applicazione.

Gli strumenti SAST eccellono nel segnalare le vulnerabilità comuni del codice e sono in grado di determinare l'esatto numero di linea e di file delle vulnerabilità trovate. Si integrano inoltre perfettamente con la maggior parte degli IDE e degli ambienti CI/CD. Detto questo, sono inclini a produrre falsi positivi.

Il test dinamico di sicurezza delle applicazioni (DAST) adotta un approccio esterno, valutando le applicazioni negli ambienti di runtime tramite attacchi simulati per imitare le azioni di attori di minacce reali. Per questo motivo, il DAST viene spesso chiamato black box testing perché i tester non hanno bisogno di conoscere o accedere al funzionamento interno o al codice sorgente di un sistema. Il DAST produce tipicamente meno falsi positivi rispetto al SAST.

L'accoppiamento SAST e DAST può svelare un quadro più completo delle potenziali vulnerabilità. Per test di sicurezza ancora più completi, SAST e DAST possono essere combinati con altri metodi, come i test interattivi di sicurezza delle applicazioni (IAST) che valutano sia il contesto del codice che il comportamento durante il runtime per segnalare le vulnerabilità in tempo reale e l'analisi della composizione del software (SCA) che analizza il software per assicurarsi che i suoi componenti siano sicuri e aggiornati.

La maggior parte delle recensioni del codice si concentra sulla qualità, esaminando il codice per verificarne la conformità alle linee guida di stile, la presenza di problemi logici, un flusso ottimale e la copertura dei test e degli edge. Tuttavia, la sicurezza deve far parte anche del processo di recensioni del codice.

Le revisioni sicure del codice funzionano come la linea di difesa successiva dietro agli analizzatori di codice statici. I revisori di codice umani offrono competenze di dominio, giudizio e insight sulle vulnerabilità della sicurezza del codice che gli strumenti automatizzati spesso trascurano.

Per un approccio più strutturato, i revisori di codice possono consultare la scheda informativa sulla revisione sicura del codice dell'OWASP.