Какие проблемы прямой вставки кода виджета в код стороннего сайта?

Еще раз благодарю всех принявшим участие в дискуссии. Наконец-то смог найти немного времени и написать небольшой обобщающий материал, может кому-то пригодится.

Итак, ситуация. Вам необходимо сделать возможность вставки своих виджетов в код сторонних сайтов. Для реализации этого сторонний сайт вставляет в свой код ваш JS-код. Далее ваш JS код вставляет виджет. Виджет можно вставить либо прямо в код страницы (далее прямая вставка в DOM) либо создать Iframe. Рассмотрим потенциальные проблемы обоих подходов.

JS конфликты
Прямая вставка в DOM
Здесь не должно быть конфликтов, когда используется “пространство имен”. Но при использовании сторонних библиотек, некоторые из них могут обращаться напрямую к window и это невозможно контролировать. Я столкнулся с проблемой когда vuetify обращается к window.$vue из своего кода и просто падает.

Iframe
Полная инкапсуляция, конфликты исключены

CSS конфликты
Прямая вставка в DOM
Потенциально очень серьёзные конфликты. Код внешнего сайта влияет на виджет, код виджета влияет на внешний сайт. Ваш виджет ломает внешний сайт, внешний сайт ломает ваш виджет.

Iframe
Полная инкапсуляция, конфликты исключены

Cookies (описанное ниже так же относится и к localStorage)
Если необходимо отправлять ваши кукисы из виджета

Прямая вставка в DOM
Мы не можем отправлять кукисы третьей-стороны из JS. Если использовать для отправки кукиса заголовки с сервера во время загрузки статики или скрытый iframe, то браузер будет опознавать их как кукисы третьей стороны. По современным оценкам кукисы третьей стороны отключены у 25-50% пользователей. И тренд такой, что это число будет только расти.

Iframe
Мы можем устанавливать свои кукисы, как кукисы первой стороны. Возможно, для некоторых браузеров, потребуется выполнить POST запрос для одобрения установки кукисов.

Безопасность
Прямая вставка в DOM
Если ваш виджет должен общаться с вашим сервером, то прямая вставка - это полный провал в безопасности. Для возможности выполнения запросов вам необходимо будет включить CORS (отключить same-origin policy). Это приведет к тому, что уязвимость, позволяющая исполнять код на внешнем сайте, позволит злоумышленнику отправлять запросы на ваш сервер от чужого имени, при стечении обстоятельств.

Еще одна проблема, если ваш виджет предоставляет какой-то функционал конечным посетителям сайта, то все их данные становятся доступны внешнему сайту (как владельцу, так и злоумышленнику способному интегрировать код). Так же владелец сайта сможет отправлять запросы от их имени. Короче, это фиаско.

Iframe
Продолжаем использовать same-origin policy. Данные виджета изолированы.

Заключение: единственный адекватный вариант - вставка через iframe.

P.S. Тимлида я обыграл. Но меня поражает: как люди с такими познаниями становятся тимлидами с зп >700к (это не Россия, но все равно дофига)?!

А в чем проблема изолирования JS?

В es5 функциональная область видимости. В es6 блочная. Этих знаний достаточно, чтобы сделать железобетонный JS. Ну и используйте переменные с блочной областью видимости - let, const.

(function(d, w){
//ваш код
})(document, window)

и всё ваш код изолирован.

По-поводу HTML тоже проблем нет, а вот с CSS вы хапанёте очень сильно. Нужно будет скидывать стили для всех сайтов. CSS раздуется до неимоверных размеров.

input {
  background-color: transparent !important;
  border: 1px solid #0de !important;
  ...
}

Если же Вы наоткуп отдаете стили, чтобы интеграторы с этим вопросом справлялись сами, то кажется, что им это не нужно. Ведь это нужно иметь штатного верстальщика и не всем он нужен. Хочется просто подключить JS и чтобы работало.

В общем, сам я больше за iframe только из-за того, что отгребу от CSS.

iframe нужно использовать для вставки кода стороннего сайта, как минимум, по причине безопасности пользователей своего сайта. Если что-то сломается или будут проблемы безопасности во вставке кода, то это не коснется твоего сайта.