@ La risposta di ThiefMaster fa un ottimo lavoro nell'enumerare i rischi dell'uso di un contenuto controllato esternamente - che fondamentalmente rientra nella categoria dell'esecuzione o della visualizzazione di codice e contenuto arbitrari sul browser di un utente.
Mi concentrerò principalmente sulla tua ultima domanda: How are those risk mitigated? che non è stata indirizzata-- molto è cambiato da allora (in 4 anni).
La difesa principale quando si includono risorse esterne da una rete CDN è quella di utilizzare Integrità della subunità (SRI) . L'SRI estende due elementi HTML con un attributo di integrità che contiene un hash crittografico della rappresentazione della risorsa che l'autore si aspetta di caricare. Nello specifico, questi sono gli elementi <script> e <link> , comunemente usati per includere rispettivamente Javascript e CSS di terze parti.
Esempi:
CSS:
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.2/css/bootstrap.min.css" integrity="sha384-y3tfxAZXuh4HwSYylfB+J125MxIs6mR5FOHamPBG064zB+AFeWH94NdvaCBm8qnd" crossorigin="anonymous">
JS:
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.2/js/bootstrap.min.js"integrity="sha384-vZ2WRJMwsjRMW/8U7i6PWi6AlO1L79snBrmgiDpgIWJ82z8eA5lenwvxbMV1PAh7" crossorigin="anonymous">
È possibile utilizzare uno o più hash, generati generalmente con openssl con codifica base64. Un browser utilizza il "più strong" che supporta.
Questo è ora supportato da Chrome e di Firefox .
Quando questi browser incontrano un elemento protetto dallo SRI, calcolano il digest e restituiscono un errore di rete se non corrisponde al risultato previsto. Per proteggere da un aggiornamento su un CDN, è possibile configurare failover , sia ad altri CDN o al tuo server.
Un'altra difesa che puoi notare sopra è l'uso dell'attributo crossorigin="anonymous" . Ciò impedisce al browser di inviare cookie al CDN, evitando così perdite CORS con un effetto collaterale della riduzione della dimensione della richiesta.
Infine, si potrebbe ottenere un beneficio molto piccolo impostando un Content-Security-Policy restrittivo che limita la superficie di attacco solo al CDN, in modo tale che anche se un CDN vulnerabile è stato infettato da un file JS diverso, non sarà direttamente in grado per accedere ai dati (anche se potrebbe attraverso il CDN).
Oltre ai vari link sopra, un altro utile riferimento è questo articolo di Mozilla Hacks .