La sicurezza Web non è un singolo interruttore da attivare una volta per tutte. È composta da più livelli, ciascuno dei quali riduce una famiglia di rischi: trasporto cifrato, controllo delle risorse caricate, limitazione delle capacità del browser, autenticazione e verifica dell’integrità.
Ragionare per livelli
HTTPS protegge il traffico tra browser e server, ma non corregge una vulnerabilità dell’applicazione. Una CSP può limitare l’impatto di alcune injection, ma non sostituisce l’escaping e la validazione. Una password robusta non compensa una cattiva gestione della sessione.
Una difesa coerente combina quindi:
- HTTPS per cifrare i dati in transito;
- header HTTP di sicurezza per dare regole esplicite al browser;
- CSP per controllare le origini autorizzate per script, stili, immagini e connessioni;
- SRI per verificare il contenuto atteso di risorse esterne;
- autenticazione e sessioni per controllare l’accesso;
- hash per confrontare integrità e impronte senza confonderli con la cifratura.
Sicurezza e privacy non sono sinonimi
Un sito può essere ben protetto da molte classi di attacco e allo stesso tempo raccogliere molti dati. Al contrario, un’applicazione Local First può limitare i trasferimenti ma deve comunque applicare le normali buone pratiche Web.
La sicurezza cerca di impedire azioni non autorizzate; la privacy cerca anche di limitare esposizione e uso dei dati. I due obiettivi si completano ma non si sostituiscono.
Partire da un modello di minaccia semplice
Prima di scegliere una protezione, chiediti che cosa vuoi impedire. Un sito vetrina, un’applicazione con account e un back-office non hanno lo stesso profilo. Identifica dati sensibili, azioni protette, risorse di terze parti, iframe e API accessibili dal browser.
Questo evita sia di installare meccanismi senza comprenderli sia di pensare che un sito “piccolo” non abbia nulla da proteggere.
HTTPS è la base, non tutta la sicurezza
HTTPS cifra il traffico e permette al browser di verificare l’identità del server tramite il certificato. Non corregge però XSS, autorizzazioni errate, password compromesse o dipendenze JavaScript pericolose.
Una volta che HTTPS è stabile su tutto il dominio, HSTS può chiedere al browser di utilizzare in modo persistente la connessione sicura.