The advantages of these SAAS solutions like easy integration and a efficient update-model are well known, but there also are some important risk that should thoroughly be evaluated before proceeding with these 3rd party includes.
Because 3rd party includes are loaded from a domain other than the origin of the actual HTML document, the browser will default to the same-origin-policy handling. This policy for example won’t allow these 3rd party scripts to use XHR for sending client data back to the 3rd party server. In a lot of situations, this same-origin-policy will be circumvented by creating hacks using browser flaws. As a result, these hacks will allow the 3rd party scripts to:
- – Instantiate browser plugins
- – Open popup windows
- – Submit forms
- – Use client side storage mechanisms like LocalStorage, SessionStorage, Cookies etc.
- – Send XHR’s
- – Manipulate the DOM of the origin page
- – Use HTC’s and Binary behaviors or bind data
An other known side effect of 3rd party includes are the so called 4th party includes, when SAAS solution providers also include external resources in their sources. These could be for example libraries from a CDN or other delivery network. This construction can introduce some nasty effects that will influence the overall quality of our websites and applications.
3rd and 4th party content owners can have a different regime or strategy in terms of caching and performance than you try to strive for. Poor or no cache settings and a poor optimization for file size and amount of io of the external sources can result in a bad overall performance of our systems. Any downtime of this external environment or resulting 500 or 404 responses even can block or stall the render-thread of the browser (white screen). The result can be an introduction of SPOF (Single Point Of Failure) on the frontend.
3rd party scripts are able to see, store and post everything the user does without any consent of you or the user. Even as a result of the expanding chain-of-trust it will be much harder or even impossible to comply to privacy regulations or perhaps even our own privacy goal. A more for the user visible effect will occur if a 4th party uses click behavior for retargeting purposes.
Because existing browser security policies are bypassed, the risk that the integrity of your systems (websites, applications) is affected, will be increased. Besides the possibility of actual exploits or attacks via XSS, an another great danger is the unnoticed realization of drive-by malware infections because of compromised 3rd and 4th parties. Frequently stories appear in the news about websites been compromised by for example the 3rd party banner network they use. Such latter case is of course extremely damaging to a corporate reputation. As a high-volume site will be popular victims.
Governance / Control
The 4th party phenomenon can result in a mush of sources and origins (domains), where the complexity of the whole increases, and the span-of-control will alarming decrease.
To cope with these issues in a sound way, it is important that awareness is created regarding 3rd party includes and the possible risks. A clear vision regarding the above should be formulated and translated into a policy. For example, a thorough risk analysis and assessment could be done. And when necessary some quality requirements could be issued through SLAs with the 3rd party. There are some interesting technically developments going on to deal in a professional way with the same-origin-policy issue when embedding 3rd party content. Things like CORS, CD Messaging and HTML5 Sandbox will in the near future be good solutions to these problems, but until then, risks should be reduced otherwise.