In una Content Security Policy e al fine di prevenire lo scripting tra siti diversi, i webmaster dovrebbero memorizzare tutti gli script in file separati e non incorporarli direttamente nel codice sorgente del proprio sito Internet. Questo indica che la CSP funziona secondo il principio della whitelist: nell’header vengono elencate le fonti da cui è possibile caricare gli script e i dati. Dunque, nel momento in cui viene inserito uno script sconosciuto nel codice HTML della pagina, il browser dell’utente deve proibire il caricamento di dati esterni. Per impostazione predefinita, la CSP blocca tutti gli script inseriti direttamente nel codice (inline scripting). Questo protegge sia il sito web che gli utenti, e soprattutto i loro dati sensibili.
Per i cybercriminali le manipolazioni tramite Cross Site Scripting sono relativamente semplici da attuare. Infatti quasi tutti i siti Internet sono dotati di un campo di input, come ad esempio la funzione di inserimento commenti, la barra di ricerca o il campo per effettuare il login: in queste sezioni, invece di inserire delle semplici parole, spesso vengono eseguiti degli script.
Dunque, se il server non è correttamente cautelato, i criminali informatici possono implementare interfacce di phishing, causare un blocco del sito web oppure utilizzare dei malware per ottenere il controllo dell’utente tramite browser. La CSP (o più precisamente: l’header corrispettivo) comunica al browser web da quali fonti è consentito caricare dei dati. Se la policy è implementata nel codice del sito web, al tentativo di recuperare quel codice introdotto tramite XSS viene risposto con un messaggio di errore.
Tramite l’utilizzo della Content Security Policy i webmaster possono modificare numerose impostazioni, ad esempio, tramite le seguenti direttive:
- base-uri: limita gli URL che possono comparire nell’elemento <base> della pagina web.
- child-src: stabilisce le fonti da cui trarre i dati che possono apparire nei frame, ad esempio i video forniti da terzi.
- connect-src: limita le fonti alle quali il sito Internet può connettersi, ad esempio tramite link.
- font-src: stabilisce da quali fonti possono essere caricati i font
- form-action: fornisce una lista di moduli endpoint validi.
- frame-ancestors: stabilisce quali domini possono strutturare la pagina in frame e iFrame.
- img-src: stabilisce da quali fonti possono essere caricate le immagini.
- media-src: determina da quali fonti possono essere caricati formati audio e video.
- object-src: controlla Flash e altri tipi di plug-in.
- plugin-types: limita le tipologie di plug-in.
- report-uri: specifica un URL a cui inviare i report in caso di violazione delle misure di sicurezza.
- script-src: determina quali fonti sono consentite per JavaScript.
- style-src: funziona come script-src, ma è usato per i fogli di stile.
- upgrade-insecure-requests: stabilisce che le pagine HTTP non protette vengano considerate come pagine HTTPS.
- sandbox: sposta la pagina in un sandbox in cui sono vietati moduli, pop-up e script.
Queste direttive sono valide solo se esplicitamente riconosciute, altrimenti restano aperte di default, costituendo così una falla di sicurezza nel sistema. Tuttavia tramite il default-src è possibile eludere questo problema: con questo metodo si stabiliscono le impostazioni di tutte le direttive che terminano con -src. Ad esempio, è possibile stabilire che il proprio sito Internet carichi soltanto i dati, a meno che non sia stato specificato diversamente nell'header HTTP di una singola pagina. Nelle direttive specifiche, inoltre, è possibile anche aggiungere atre fonti.
Nell’header è possibile immettere un numero potenzialmente infinito di direttive. Se si desidera includere più direttive, è necessario separarle con punto e virgola. Inoltre, il webmaster deve specificare tutte le sorgenti e le fonti all’interno di una direttiva. Non sono consentite citazioni multiple delle stesse direttive con fonti aggiuntive. L’esempio seguente mostra un comando non ammesso: