¿Cómo protegerse contra este tipo de ataques de skimmer cuando los sitios web modernos dependen tanto de las bibliotecas de JavaScript de terceros?
Respuesta simple, no puedes. Si utiliza una biblioteca de terceros haciendo referencia a ella por URL y no copiando los archivos de la biblioteca en su sitio, confíe en que el encargado de la biblioteca de terceros haga su trabajo (lo mantendrá a salvo).
Los malhechores lo saben e intentan infiltrarse en estas bibliotecas de terceros.
Más información técnica sobre el tema: enlace
Opción 1: no utilice bibliotecas de terceros.
Opción 2: copie los archivos de JavaScript reales en su sitio *, elimine todo el código no utilizado, manténgalos usted mismo (está creando una bifurcación, se agregará después de los comentarios) * a̶n̶d̶ ̶u̶s̶e̶ ̶t̶h̶e̶m̶ ̶f̶r̶o̶m̶ ̶t̶h̶e̶r̶e̶. Deberá asegurarse de que tiene permiso para hacer esto (por ejemplo, derechos de autor, licencia); es posible que se apliquen obligaciones.
EDITAR (después de un comentario):
No importa lo que use, si carga recursos de terceros, cualquier recurso, incluso encriptado, confía en que el tercero lo mantenga seguro. Incluso la opción 2 (Copiar los archivos) no es segura, a menos que usted revise cada línea de cada archivo que haya copiado e incluso entonces ... La opción 1 es, imho, la única manera de estar seguro.
La opción 2 es más segura que enlazar a recursos remotos porque el punk tendría que cambiar el código en su servidor (siempre que el código esté "limpio" cuando lo copió), y si tiene un punk en su servidor. servidor entonces tienes otros problemas ...
Cualquier tercera parte puede potencialmente ser derrotada y atraerá más atacantes si se usa ampliamente. Esto ya sucedió en el pasado, con punks inyectando cryptominers en bibliotecas de JavaScript, derrotando a Subresource Integrity, el código se introdujo en las bibliotecas, el servidor de 3rdparty "pensó" que el código era genuino ... no estoy seguro de qué sucedió con BA, cómo Los cambios introducidos en el sitio web ...