What are the problems of directly inserting the widget code into the code of a third-party site?

Question

css

Hello community!

I recently joined a team where they are working on a project whose idea
is that users can create a form on our platform and then they can insert it into their site (submitting data from the form also goes to our project and our database). In fact, it's a widget. In general, this is a clone: ​​jotform.com only with its own blackjack.

Actually, here's the problem. The current implementation of the form widget is done in Vue and the integration goes straight into the code of the external site. Those. our DOM and JS are straight into the site's DOM.

And we had a dispute with the team leader. The team leader says that the project's feature is the insertion directly into the code and the ability of the site owners to influence the form code (such as apply CSS). And JS is easy to isolate through namespace.

My opinion is that this way of integration is just a game. And you can't do that. You need to use an iframe or a web component. And to influence the CSS, just allow you to specify your CSS through the field in the form setup.

Dear experts, please express your opinion on the approaches. What can be the problems with direct insertion into the code of an unknown site? Is it really easy to isolate the JS in this case and only the CSS/HTML influence will be the problem?

PS If there are links to interesting materials on the topic, especially in English, I will be very grateful.

Answer 1

Thanks again to everyone who took part in the discussion. Finally, I was able to find some time and write a small generalizing material, maybe it will be useful to someone.
So the situation. You need to make it possible to insert your widgets into the code of third-party sites. To implement this, a third-party site inserts your JS code into its code. Next, your JS code inserts the widget. The widget can be inserted either directly into the page code (hereinafter referred to as direct insertion into the DOM) or create an Iframe. Let's consider the potential problems of both approaches.
There should be no conflict here when "namespace" is used. But when using third-party libraries, some of them can access window directly and this cannot be controlled. I ran into a problem where vuetify calls window.$vue from my code and just crashes.
Full encapsulation, no conflicts
Potentially very serious conflicts. The external site code affects the widget, the widget code affects the external site. Your widget breaks the external site, the external site breaks your widget.
Full encapsulation, no conflicts
If you want to send your cookies from a widget
We cannot send 3rd party cookies from JS. If you use headers from the server during static loading or a hidden iframe to send the cookie, the browser will recognize them as third party cookies. According to modern estimates, third-party cookies are disabled for 25-50% of users. And the trend is such that this number will only grow.
We can set our cookies as first party cookies. Some browsers may require a POST request to accept the setting of cookies.
If your widget needs to communicate with your server, then direct insertion is a total security fail. To be able to make requests, you will need to enable CORS (disable same-origin policy). This will result in a vulnerability that allows code to be executed on an external site, allowing an attacker to send requests to your server under someone else's name, under the circumstances.
Another problem, if your widget provides some functionality to the end visitors of the site, then all their data becomes available to the external site (both the owner and the attacker who is able to integrate the code). Also, the site owner will be able to send requests on their behalf. In short, it's a fiasco.
continue to use the same-origin policy. Widget data is isolated.
Conclusion:the only adequate option is insertion through an iframe.
PS Timlid I beat. But it amazes me: how do people with such knowledge become team leads with salary> 700k (this is not Russia, but still dofiga) ?!

Answer 2

IMHO, the team leader is right, there shouldn't be any problems in case of strict encapsulation of the entire JS code. If you need interaction with external code, you can provide a single variable to implement some kind of client API.
Problems can be when processing incoming data from unknown sites on the server. This is where you need to filter everything.