Content Security Policy (CSP) è un meccanismo del browser che consente ai creatori di applicazioni di definire quali risorse possono essere caricate ed eseguite nel contesto della pagina. Grazie a CSP è possibile ridurre in modo significativo il rischio di attacchi di tipo cross‑site scripting (XSS) e di altri comportamenti indesiderati, come l’iniezione di codice JavaScript non autorizzato. In ambienti basati su Next.js e React, dove i componenti vengono renderizzati dinamicamente, l’implementazione di CSP richiede una configurazione ponderata per non compromettere la funzionalità dell’applicazione.
Modello di minaccia – perché CSP è necessario nelle applicazioni React/Next.js
Le moderne applicazioni front‑end spesso caricano script da molteplici fonti: CDN, server proprietario e anche script inline generati dinamicamente (ad es. incorporati nei template HTML). Un aggressore può sfruttare vulnerabilità nella sanitizzazione dei dati in ingresso per iniettare codice JavaScript proprio, portando al furto di token, sessioni o all’esecuzione di operazioni non autorizzate. CSP agisce come livello difensivo, bloccando le fonti non autorizzate e imponendo l’uso di metodi sicuri per il caricamento delle risorse.
Come funziona CSP – direttive di base e loro significato
La politica CSP è definita nell’intestazione HTTP Content‑Security‑Policy o nel tag <meta>. Le direttive più importanti sono:
default-src– fonte predefinita per tutti i tipi di risorse, se non è specificata un’altra direttiva.script-src– controlla da dove possono provenire gli script JavaScript.style-src– specifica le fonti consentite per i fogli di stile CSS.img-src– regola l’origine delle immagini.connect-src– definisce a quali indirizzi l’applicazione può stabilire connessioni (ad es. API, WebSocket).
In pratica la più importante è script-src, poiché protegge direttamente contro XSS. Si consiglia di utilizzare hash ('sha256-…') o nonce ('nonce‑…') per gli script inline, invece di affidarsi a 'unsafe-inline', che disattiva la protezione.
Esempio di politica CSP per Next.js
Di seguito è riportata una politica CSP minima ma efficace, che può essere aggiunta nel file next.config.js tramite middleware o nella funzione getServerSideProps:
module.exports = {
async headers() {
return [
{
source: '/(.*)',
headers: [
{
key: 'Content-Security-Policy',
value: "default-src 'self'; script-src 'self' 'sha256-abc123' https://cdn.jsdelivr.net; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' https://api.example.com; font-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'"
}
]
}
];
}
};
Questa politica consente solo script provenienti dall’host stesso e da un CDN fidato, mentre gli script inline devono essere protetti con un hash. Per gli stili è stato consentito 'unsafe-inline' solo in casi eccezionali, come compromesso necessario quando si usano librerie CSS‑in‑JS.
Fragmenti di codice: vulnerabile vs. corretto
Consideriamo un semplice componente React che inserisce contenuto ottenuto da un’API senza sanitizzazione:
function UnsafeComponent({html}) {
return ;
}
Questo approccio è vulnerabile a XSS, poiché qualsiasi codice HTML può essere eseguito. La versione corretta utilizza una libreria di sanitizzazione e limita al contempo CSP a fonti fidate:
import DOMPurify from 'dompurify';
function SafeComponent({html}) {
const cleanHtml = DOMPurify.sanitize(html);
return ;
}
La combinazione di sanitizzazione lato applicazione con una politica CSP restrittiva aumenta significativamente il livello di sicurezza.
“CSP non è uno scudo magico – è un elemento della difesa a più livelli che deve coesistere con codice sicuro.”
Checklist per l’implementazione di CSP in Next.js e React
- Identifica tutte le fonti di script, stili, immagini e connessioni utilizzate nel progetto.
- Stabilisci quali script inline sono indispensabili; sostituiscili con hash o nonce.
- Configura l’intestazione CSP in
next.config.jso sul server proxy (NGINX, Vercel). - Abilita il reporting CSP (direttiva
report-urioreport-to) e monitora i log. - Testa la politica in modalità report (
Content-Security-Policy-Report-Only) prima di attivarla in modalità blocco. - Utilizza gli strumenti di sviluppo del browser per analizzare le violazioni CSP e affinare la politica.
Errori comuni e compromessi nell’implementazione di CSP
Le trappole più frequenti sono:
- Utilizzare
'unsafe-inline'o'unsafe-eval'– disattiva completamente la protezione contro XSS. - Hash obsoleti – dopo una modifica del codice l'hash deve essere aggiornato, altrimenti la policy blocca il codice legittimo.
default-srctroppo restrittivo senza un adeguato allineamento delle sotto‑direttive – può causare il mancato caricamento di risorse necessarie, ad esempio font o immagini.- Mancanza di reporting – senza il reporting attivato è difficile individuare quali risorse vengono bloccate e perché.
La soluzione è un approccio iterativo: prima attivare la policy in modalità Report‑Only, raccogliere i dati e poi passare alla modalità di blocco dopo aver eliminato tutti i falsi positivi.
Debug delle violazioni CSP nel browser e reporting
Nel console developer di Chrome e Firefox compaiono messaggi del tipo Refused to load the script … because it violates the following Content Security Policy directive: "script-src …". Cliccando sul messaggio si apre un'anteprima della risorsa bloccata. Inoltre, se è configurato report-uri, il server riceve un JSON con le informazioni sulla violazione, consentendo un'analisi automatica e l'aggiornamento della policy.
Manutenzione e aggiornamento della policy CSP
La policy CSP non è una configurazione una tantum – richiede revisioni regolari. Ogni nuova libreria, CDN o funzionalità (ad esempio WebSocket) può richiedere l'aggiunta delle fonti appropriate alle direttive. Una buona pratica è integrare test e2e che verifichino il corretto funzionamento dell'applicazione con CSP attivo, oltre a monitorare i report in un sistema SIEM o su un endpoint dedicato.
In sintesi, l'implementazione di Content Security Policy nei progetti Next.js e React è un processo che combina un inventario accurato delle risorse, una configurazione corretta degli header e un monitoraggio continuo. In questo modo il team di ingegneria può ridurre significativamente il rischio di XSS mantenendo piena la funzionalità dell'applicazione. Se hai bisogno di assistenza per un audit di sicurezza, la configurazione di CSP o l'integrazione del reporting, contattaci su Coderia.it – costruiremo insieme una solida barriera protettiva per il tuo codice.
