In breve
- La sicurezza web si regge su tre pilastri: non fidarsi dell'input, aggiornare tutto lo stack, ridurre la superficie d'attacco.
- Il riferimento e' la OWASP Top 10:2025: controllo accessi difettoso, errori crittografici, supply chain, injection, XSS.
- Contro le SQL injection si usano sempre query parametrizzate; contro l'XSS, escaping in uscita e validazione lato server.
- Le dipendenze di terze parti sono il rischio in maggiore crescita: inventario, scanner automatici e aggiornamenti regolari.
- Backup testati, log e un piano di risposta contano quanto la prevenzione, anche per gli obblighi GDPR.
In sintesi
La sicurezza web è l'insieme di pratiche che protegge un sito o una web application da attacchi, furti di dati e interruzioni di servizio. La sicurezza di un sito web o di una web application si costruisce su tre livelli: scrivere codice che non si fida mai dell'input dell'utente, tenere aggiornato tutto lo stack, e ridurre la superficie d'attacco con configurazioni e header corretti. Non e' un prodotto da installare una volta: e' un insieme di pratiche che accompagnano tutto il ciclo di vita dell'applicazione. Il riferimento di settore e' la OWASP Top 10, aggiornata nel 2025, che elenca le categorie di rischio piu' critiche: controllo degli accessi difettoso, errori crittografici, vulnerabilita' della supply chain software, injection. Questa guida spiega, in modo pratico e senza gergo inutile, le minacce piu' comuni per un sito e le contromisure che contano davvero per una PMI.
Sicurezza web: da cosa devi difendere un sito?
Le minacce reali per un sito o una web application di una PMI non sono attacchi mirati da film: sono automatismi che scansionano internet in cerca di errori noti.
Le categorie piu' frequenti, in linea con la OWASP Top 10:2025:
- Controllo degli accessi difettoso: un utente riesce a vedere o modificare dati che non gli competono (l'ordine di un altro cliente, un'area riservata) cambiando un parametro nell'URL.
- Injection (SQL, comandi): input malevolo che viene interpretato come codice dal database o dal sistema.
- Cross-Site Scripting (XSS): JavaScript ostile iniettato in una pagina e poi eseguito nel browser di altri utenti.
- Errori crittografici: dati sensibili trasmessi o salvati senza cifratura adeguata, password conservate male.
- Vulnerabilita' della supply chain: una libreria di terze parti compromessa o non aggiornata che apre una porta nell'applicazione.
- Configurazioni errate: pannelli di amministrazione esposti, messaggi di errore che rivelano dettagli interni, permessi troppo larghi.
Quasi tutti questi attacchi sfruttano una fiducia mal riposta: nell'input, in una dipendenza, in una configurazione di default.
Non fidarti mai dell'input: injection e XSS
La regola che previene la maggior parte delle vulnerabilita' applicative e' una sola: ogni dato che arriva dall'esterno e' potenzialmente ostile finche' non e' stato validato e trattato nel modo giusto.
Contro le SQL injection: mai costruire query concatenando stringhe con l'input dell'utente. Si usano sempre query parametrizzate (prepared statement), dove i valori viaggiano separati dal comando SQL.
```php
// Query parametrizzata: l'input dell'utente non finisce mai nella stringa SQL
$stmt = $pdo->prepare('SELECT id, nome FROM utenti WHERE email = ?');
$stmt->execute([$email]);
$utente = $stmt->fetch();
```
Contro l'XSS: ogni dato inserito dall'utente e poi mostrato in pagina va codificato in uscita (escaping HTML), cosi' che un eventuale `<script>` venga visualizzato come testo e non eseguito. I framework moderni (React, ad esempio) lo fanno di default, ma le eccezioni (contenuto HTML "grezzo") vanno gestite con attenzione.
Validazione in ingresso: accettare solo cio' che ha senso (tipo, formato, lunghezza, intervallo) e rifiutare il resto, sia lato client sia, soprattutto, lato server.
Autenticazione, accessi e sessioni
Il controllo degli accessi difettoso e' la categoria numero uno della OWASP Top 10 da diversi anni. Le contromisure di base:
- Password: obbligo di lunghezza minima, blocco dei valori piu' comuni, hashing con algoritmi lenti e dedicati (bcrypt, Argon2), mai in chiaro o con hash veloci.
- Autenticazione a due fattori (2FA) almeno per gli account amministrativi.
- Autorizzazione controllata a ogni richiesta: il server deve verificare che l'utente possa davvero accedere a quella risorsa, non fidarsi del fatto che l'interfaccia non mostri il pulsante. Cambiare un ID nell'URL non deve mai bastare per vedere i dati di un altro.
- Sessioni: cookie con flag `HttpOnly` e `Secure`, scadenza ragionevole, rigenerazione dell'identificativo di sessione al login, logout che invalida davvero la sessione.
- Protezione dai tentativi automatici: rate limiting sui login, ritardi progressivi, CAPTCHA dove serve.
HTTPS, header di sicurezza e superficie d'attacco
Il trasporto cifrato non e' opzionale. Un certificato TLS (HTTPS) protegge i dati tra browser e server ed e' anche un fattore di ranking per Google. Va accompagnato da alcuni header che chiudono classi intere di attacchi:
```php
// Header di sicurezza minimi per una web application (esempio PHP)
header("Content-Security-Policy: default-src 'self'");
header('X-Content-Type-Options: nosniff');
header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
header('Referrer-Policy: strict-origin-when-cross-origin');
```
- Content-Security-Policy: limita da dove la pagina puo' caricare script e risorse, mitigando l'XSS.
- Strict-Transport-Security (HSTS): forza il browser a usare sempre HTTPS.
- X-Content-Type-Options: nosniff: impedisce al browser di "indovinare" il tipo di un file.
Riduci poi la superficie d'attacco: disattiva cio' che non usi, non esporre pannelli di amministrazione su URL prevedibili senza protezioni aggiuntive, non lasciare in produzione messaggi di errore dettagliati, tieni separati gli ambienti di test e di produzione.
Dipendenze e supply chain: il rischio che cresce di piu'
La OWASP Top 10:2025 ha introdotto una categoria dedicata ai fallimenti della supply chain software, segno di quanto pesi oggi il codice di terze parti. Una web application moderna usa decine o centinaia di librerie: ognuna e' un potenziale punto d'ingresso.
Pratiche minime:
- Inventario delle dipendenze e aggiornamenti regolari, non solo quando qualcosa si rompe.
- Scanner automatici delle vulnerabilita' note integrati nel processo di sviluppo e nella pipeline di rilascio.
- Blocco delle versioni (lockfile) per rilasci ripetibili, con aggiornamenti controllati e testati.
- Meno dipendenze possibili: ogni libreria in piu' e' codice che non hai scritto e non controlli del tutto.
Lo stesso vale per il CMS o il framework alla base del sito: aggiornamenti e patch di sicurezza vanno applicati in tempi rapidi, con una procedura, non a discrezione.
Backup, monitoraggio e piano di risposta
La sicurezza perfetta non esiste: conta anche quanto in fretta ti accorgi di un problema e quanto velocemente torni operativo.
- Backup automatici e testati: sia del database sia dei file, con copie fuori dal server principale e una verifica periodica che il ripristino funzioni davvero.
- Log e monitoraggio: accessi anomali, picchi di errori, tentativi di login falliti. Un alert che arriva in tempo vale piu' di un report letto a posteriori.
- Aggiornamenti come routine: una finestra pianificata, non un intervento d'emergenza.
- Un referente tecnico che sappia cosa fare se qualcosa va storto: chi isolare, chi avvisare, come comunicare.
Per le web application che trattano dati personali, questo si intreccia con gli obblighi del GDPR: misure adeguate, capacita' di rilevare una violazione e, se serve, di notificarla.
Sicurezza per progetti su misura vs pacchetti pronti
Un sito costruito su un CMS diffuso eredita sia i vantaggi (aggiornamenti frequenti, community) sia i rischi (bersaglio noto, plugin di qualita' variabile). Una web application sviluppata su misura ha meno codice "di serie" da attaccare, ma la responsabilita' delle scelte di sicurezza e' interamente di chi la sviluppa: vanno messe nel progetto fin dall'inizio, non aggiunte alla fine.
ControlCode sviluppa siti e web application per PMI con la sicurezza come requisito di progetto: query parametrizzate e validazione ovunque, gestione corretta di autenticazione e sessioni, header e HTTPS configurati, dipendenze sotto controllo, backup e monitoraggio inclusi nel contratto di assistenza. Sede a Comazzo (LO).
In conclusione
Proteggere un sito web non richiede strumenti esotici: richiede metodo. Non fidarsi mai dell'input, tenere aggiornato tutto lo stack (dipendenze comprese), usare HTTPS e gli header giusti, gestire bene accessi e sessioni, avere backup testati e un minimo di monitoraggio. La OWASP Top 10 e' la mappa da cui partire. Se stai sviluppando un sito o una web application e vuoi che la sicurezza sia parte del progetto e non una toppa, parliamone: ne valutiamo insieme i requisiti. In pratica, la sicurezza si costruisce un livello alla volta: prima gli accessi, poi le dipendenze, poi il monitoraggio. Rimandare la sicurezza a dopo il lancio è l'errore più comune e più caro da correggere.
Approfondimenti correlati
Domande frequenti
Scritto da
Riccardo Rizzini
Sviluppatore Web & Fondatore di ControlCode
Riccardo Rizzini è sviluppatore web e fondatore di ControlCode, team multidisciplinare operativo su Milano e provincia. Da oltre 8 anni progetta siti, web app e software gestionali su misura per PMI italiane, con focus su performance, SEO tecnica e ottimizzazione per la ricerca AI.