how to you protect against these kinds of skimmer attacks when modern websites rely so much on third party javascript libraries?
Risposta semplice, non puoi. Se si utilizza una libreria di terze parti facendo riferimento a tale URL e non copiando i file di libreria effettivi sul proprio sito, ci si può fidare che il manutentore di librerie di terze parti svolga il suo lavoro (per sicurezza).
I miscredenti lo sanno e si sforzano molto per infiltrare il codice in queste librerie di terze parti.
Ulteriori informazioni tecniche sull'argomento: link
Opzione 1: non utilizzare librerie di terze parti.
Opzione 2: copia i file JavaScript effettivi sul tuo sito *, elimina tutto il codice inutilizzato, mantienilo da solo (stai creando un fork - aggiunto dopo i commenti) * a̶n̶d̶ ̶u̶s̶e̶ ̶t̶h̶e̶m̶ ̶f̶r̶o̶m̶ ̶t̶h̶e̶r̶e̶. Dovrai assicurarti di essere autorizzato a farlo (ad es. Copyright, licenza), potrebbero essere applicati degli obblighi.
EDIT (dopo un commento):
Non importa ciò che usi, se carichi risorse da terze parti, qualsiasi risorsa, anche crittografata, ti fidi della terza parte per tenerti al sicuro. Anche l'opzione 2 (Copia dei file) non è sicura, a meno che non controlli ogni riga di ogni file che hai copiato e anche allora ... L'opzione 1 è, imho, l'unico modo per essere sicuro.
L'opzione 2 è più sicura del collegamento alle risorse remote perché il punk dovrebbe cambiare il codice sul tuo server (a condizione, ovviamente, che il codice fosse "pulito" quando lo hai copiato) e se hai un punk sul tuo server allora hai altri problemi ...
Qualsiasi terza parte può potenzialmente essere sconfitta e attirerà più attaccanti se è ampiamente utilizzata. Questo è già accaduto in passato, con i punk che hanno iniettato cryptominers nelle librerie JavaScript, sconfiggendo l'integrità delle subunità, il codice era nascosto nelle librerie, il server di terze parti "pensava" che il codice fosse autentico ... non sono sicuro di quello che è successo con BA, come le modifiche sono entrate nel sito web ...