Published on March 11th, 2019
Written by Sanjay Sawhney, Co-Founder and VP of Engineering

Javascript Insertion

The weakest link in a modern web application is external JavaScript - something that has been exploited in recent attacks such as (Magecart, British Airways, Newegg…)In the recent study, Security Challenges in an Increasingly Tangled Web [1], it was determined that when a user visits a website roughly 2/3 of the code running in the browser comes from 3rd parties (analytics, tag management, audio/video integration, form builders, social media, etc.). So, how do you defend the user of a webapp from threats resulting from the compromise of these 3rd party components as they are fetched in real time within a browser? A couple of approaches that have been touted rely on injecting heavyweight Javascript as a layer of defense into a web page when the page is served from the website. The purpose of this layer of JavaScript is to hook onto key JavaScript APIs in a browser (as the user is visiting the page), instrument access and flow of data, and/or to provide a layer of application sandboxing (aka virtual iframe) within a browser. These approaches, what one would call “JavaScript versus JavaScript” (like a war within a browser between the attacker’s JavaScript and the layer of defense’s JavaScript), are flawed for a variety of reasons that are highlighted below.

Website Performance

The time your developers and application owners have spent on optimizing page load times is futile the moment you inject this heavyweight JavaScript as a layer of defense. There is an increase in page latency, load time and time to execute the code within the browser (as this JavaScript defense layer often duplicates functions within a browser such as parsing JS/HTML and maintaining state machines). Secondly, hooking onto network calls to monitor outbound post requests, web socket connections, calls to local file system or reads/writes to/from the parent DOM is very expensive to do in a browser. On an average page, there are at least 75+ such events that’ll now be monitored with JavaScript hooking, significantly slowing down the end user experience on the web page. CDNs and load balancers cannot rescue you from such performance issues because the slowdown is not over the network but due to the additional code running within a browser.


We know what you're thinking. Isn’t giving up on performance worth it to get strong security? The golden rule in the security world is that the layer of defense should run at a higher privilege level than the layer of attack AND retain enough visibility to understand the context of the layer at which the attack happens. Running at the same privilege as the attacker’s code is an absolute NO NO! Hardware level defenses are superior to software level defenses. Kernel level defenses are stronger than user space defenses. OS level defenses are superior to defenses inside an application. The concept of TCB (Trusted Computing Base) and a defense mechanism ideally as part of TCB, has been explored way back in the classic paper, Authentication in Distributed Systems: Theory and Practice, ACM Transactions on Computer Systems 1992 [2]. In the current discussion, the browser, the JavaScript interpreter and the OS are the TCB. The defense mechanism protecting a component outside the TCB, should ideally reside in the TCB. Therefore, browser or JavaScript interpreter level defenses [3], which are part of the TCB, are much more difficult to circumvent than a pure JavaScript layer of defense (running as is or presenting itself as a virtual sandbox) layered on top of a browser. Any approach that explicitly or implicitly assumes that my JavaScript layer of defense is smarter than the attacker's JavaScript is flawed. Having application virtualization implemented at JS level to confine code between custom HTML tags (virtual iframes) is an insecure implementation of the virtual sandbox concept.

Deployment Challenges

JavaScript injection approaches are too intrusive with a high potential for breaking existing apps. The defense layer of JavaScript could interfere with legitimate JavaScript running on that page. How much effort does one want to spend on testing each and every page and pulling in your developers to troubleshoot? The developers will definitely not be happy while debugging real issues and trying to figure out whether the fault is with their code or with this other piece of code. In deploying virtual sandboxing how does one know, without involving the developers, which data flows are legitimate and which are not? Try determining this for a site that has 30k+ pages. One customer, trying a product based on virtual sandboxing, is still struggling even after spending almost a year on it.

Strengthen Against JavaScript Attacks

Securing your web application against JavaScript attacks with JavaScript has a negative impact on security, performance and intrusiveness. These attacks are best addressed by leveraging W3C compliant native controls available within 90% of PC & mobile browsers OR emerging JavaScript interpreters.


[1] D. Kumar, Z Ma, et. al., Security Challenges in an Increasingly Tangled Web

[2] B. Lampson, M. Abadi, M. Burrows and E. Wobber, Authentication in Distributed Systems: Theory and Practice, ACM Transactions on Computer Systems 1992, on page 6.

[3] D Stefan, et. al., Protecting Users by Confining JavaScript with COWL,

Sanjay Sawhney, Co-Founder and VP of Engineering

Sanjay Sawhney, Co-Founder and VP of Engineering

Sanjay Sawhney is the co-founder and VP of Engineering of Tala. Sanjay is an experienced, engineering leader, technologist and entrepreneur who has worked for 25+ years in various engineering capacities in both well-established companies as well as startups. Most recently, he spent 9 years at Symantec managing Symantec Research Labs, one of the key innovation engines of the company. Prior to joining Symantec, he co-founded two companies and led their engineering – Neoscale Systems, a data encryption company, and Ukiah Software, a network security company. Earlier in his career, he has worked in various engineering positions at Novell. Sanjay received a B.Tech. in Electrical Engineering from Indian Institute of Technology, Delhi, and an M.S. in Computer Science from University of California, Santa Barbara.

Find Sanjay on LinkedIn


Sign up for our Newsletter

Hand-picked security content for security professionals.