Una Content Security Policy indica al browser quali sorgenti di contenuto sono autorizzate. È particolarmente utile per limitare l’impatto di alcune injection di script e impedire caricamenti da origini inattese.
GuidaBuone pratichePrincipiante
Content Security Policy (CSP): ridurre i rischi XSS e i caricamenti indesiderati
Impara a costruire una CSP progressiva, comprenderne le direttive ed evitare policy troppo permissive o che rompono il sito.
Mostra indice
Una CSP è una lista di autorizzazioni
Direttive come default-src, script-src, style-src, img-src, connect-src e frame-ancestors coprono famiglie diverse di risorse. Una policy efficace deve riflettere i bisogni reali dell’applicazione invece di accumulare domini “per sicurezza”.
Un generatore CSP può produrre una base leggibile, ma va considerato un punto di partenza da testare, non una garanzia automatica.
Procedere gradualmente
Applicare subito una policy estremamente restrittiva su un sito esistente può rompere analytics, widget, font, immagini o chiamate API. È più prudente inventariare le risorse, costruire una policy minima, testare le pagine importanti e restringere progressivamente le regole.
Evita di risolvere ogni errore aggiungendo wildcard molto ampie. Ogni eccezione dovrebbe corrispondere a un’esigenza compresa.
Nonce, hash e script inline
Gli script inline sono un punto delicato. Nonce e hash permettono di autorizzare contenuti specifici senza aprire globalmente unsafe-inline. La scelta dipende da come l’applicazione genera le pagine.
Anche unsafe-eval merita attenzione: autorizza forme di valutazione dinamica del codice e dovrebbe essere usato solo quando la necessità è chiara e non eliminabile con una configurazione diversa.
frame-ancestors e iframe
La direttiva frame-ancestors controlla quali origini possono integrare la pagina in un iframe. È utile contro alcune forme di clickjacking e completa gli altri header di sicurezza.
Comprendere il fallback delle direttive
default-src agisce come regola di fallback per diverse categorie quando non esiste una direttiva più precisa. Se aggiungi script-src, per gli script valgono le regole specifiche di script-src.
Una policy tipica distingue almeno script, stili, immagini, connessioni e frame. A seconda del sito possono essere utili anche font-src, media-src, worker-src, object-src, base-uri o form-action. L’obiettivo non è usare ogni direttiva possibile, ma descrivere con precisione il comportamento atteso.
Usare Report-Only durante la messa a punto
Content-Security-Policy-Report-Only permette di osservare le violazioni senza bloccare subito le risorse. Su un sito esistente è utile per navigare le pagine, attivare le funzionalità e distinguere origini legittime da caricamenti inattesi.
Report-Only resta però una fase di test. Quando la policy è stabile, la protezione effettiva richiede l’header Content-Security-Policy.
Esempio di progressione
Puoi partire dall’inventario delle risorse, impostare default-src 'self', aggiungere esplicitamente i domini indispensabili per immagini, API e servizi terzi, quindi trattare con particolare attenzione gli script. Regole come object-src 'none', base-uri e frame-ancestors possono poi completare la configurazione.
CSP non significa “XSS impossibile”
La CSP è una difesa in profondità. Non sostituisce encoding delle uscite, validazione, autorizzazione o correzione delle vulnerabilità applicative. Una policy debole o mal progettata può persino creare una falsa sensazione di sicurezza.
Una policy evolve con il sito
Aggiungere analytics, un player video, font remoti o una nuova API può richiedere una modifica. Considera ogni nuova origine come un’estensione esplicita del modello di fiducia, non come un motivo per inserire * ovunque.
Per alcune risorse statiche esterne, SRI può aggiungere un controllo complementare: CSP decide da dove può arrivare una risorsa; SRI può verificare quale contenuto esatto è stato ricevuto.