CSP

CSP (Content Security Policy) è un header di risposta HTTP che indica ai browser quali fonti di contenuto la pagina si fida. Definisce whitelist per tipo di contenuto: script-src per JavaScript, style-src per CSS, img-src per le immagini, connect-src per fetch/XHR/WebSocket, frame-src per iframe, ecc.

Header di esempio: Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:.

Il valore principale di CSP: difesa in profondità contro XSS. Anche se un attaccante inietta JavaScript nella pagina, una CSP rigorosa impedisce al browser di eseguirlo (perché caricato da un’origine non presente nella whitelist) o di inviare dati ovunque (perché connect-src blocca l’esfiltrazione verso i domini dell’attaccante).

Best practice moderna: usare una CSP basata su nonce — ogni risposta della pagina include un nonce casuale nel suo header CSP (es. script-src 'nonce-AbC123') e i tag script inline che corrispondono a quel nonce possono essere eseguiti. Questo è restrittivo ma consente di distribuire contenuto dinamico in modo sicuro. Analizzatori statici come il CSP Evaluator di Google valutano la policy e segnalano le debolezze.

Errori comuni di CSP che vanificano lo scopo: usare 'unsafe-inline' in script-src (riabilita l’iniezione inline che si stava cercando di bloccare), usare il carattere jolly https: come fonte di script (qualsiasi host HTTPS può ora servire JS alla propria origine), o fidarsi di un host CDN compatibile con JSONP che consente agli attaccanti di creare un URL che restituisce JavaScript controllato dall’attaccante. Il paper del 2016 “CSP Is Dead, Long Live CSP!” del team di sicurezza di Google ha mostrato che il 95% delle policy in uso erano banalmente aggirabili esattamente per queste ragioni; 'strict-dynamic' + nonce era la correzione proposta ed è ora la raccomandazione predefinita.

CSP segnala le violazioni delle policy a un URL specificato in report-uri (deprecato) o report-to. Distribuire prima una nuova policy in modalità Content-Security-Policy-Report-Only — il browser segnalerà le violazioni senza bloccare il contenuto, consentendo di correggere le fonti legittime prima dell’applicazione. Correlati: XSS, CORS, SRI (Subresource Integrity). Riferimento: W3C CSP Level 3.

Un esempio misurato: come funziona strict-dynamic

Una policy reale e rigorosa appare così: Content-Security-Policy: script-src 'nonce-r4nd0m' 'strict-dynamic' https:; object-src 'none'; base-uri 'none'. Il server genera un nuovo nonce a 128 bit per risposta (tipicamente 22 caratteri base64url), lo incorpora nei tag <script nonce="r4nd0m"> corrispondenti e invia l’header. strict-dynamic propaga la fiducia in modo transitivo: gli script caricati dallo script con nonce possono a loro volta caricare ulteriori script senza whitelisting esplicito, ma gli script iniettati senza nonce nel sorgente della pagina vengono bloccati. Il CSP Evaluator di Google valuta le policy su una scala da 0 a 10; una policy strict-dynamic senza 'unsafe-inline' e senza caratteri jolly host ottiene 9+, mentre una policy legacy tipica con sorgenti CDN con caratteri jolly ottiene 1-3. Lo stesso studio Google su 1,6 milioni di policy nell’Alexa top million ha rilevato che l’aggiunta di strict-dynamic ha ridotto la quota aggirabile per XSS dal 95% a meno del 5%.

Come CSP interagisce con le funzionalità del browser

CSP blocca più della semplice esecuzione degli script. connect-src limita fetch, XHR, WebSocket, EventSource e la Beacon API — utile per bloccare l’esfiltrazione di dati anche dopo un XSS riuscito. frame-ancestors sostituisce il più vecchio header X-Frame-Options per la protezione dal clickjacking. upgrade-insecure-requests riscrive automaticamente gli URL delle sottorisorse HTTP in HTTPS. require-trusted-types-for 'script' fa optare la pagina nell’API Trusted Types, che forza tutti i sink DOM (innerHTML, eval, ecc.) ad accettare solo oggetti di tipo speciale, bloccando DOM-based XSS alla fonte. I browser moderni inviano i report delle violazioni come JSON all’endpoint report-to, in batch tramite la Reporting API. Riferimento: Paper ACM CCS 2016 di Google “CSP Is Dead, Long Live CSP!”.