Published on October 2nd, 2019
Written by Deepika Gajaria, Senior Director, Product Management

Fifteen years ago, when a user visited a website, all the logic and processing happened on the server. The client device received mostly HTML and the browser or the client app would primarily be a rendering engine. Fast forward a few years and two key developments altered the architecture of web applications we know of today.

With the release of the iPhone and the growth in mobile devices, there was a strong need to support mobile applications over weakly connected, intermittently connected, or high delay networks. These web applications needed to work offline or in a disconnected mode. Companies like Google wanted users of their cloud-hosted applications, such as Google Docs, to have the same experience of working on Microsoft Office as on their desktop. If any changes were made to a spreadsheet, all computations took place locally, on the browser, instead of making round trips to the web server.

These two key developments led to many modern web applications using client heavy frameworks such as Angular, Ember, React, Backbone, etc. When a user visits a website, the browser loads a significant amount of JavaScript from the site and executes that code directly on the client browser. It is fair to say that the browser has become the new OS. Many web apps are “Single Page Apps” that are JavaScript heavy apps making API calls to retrieve data from the server backend. Visiting a modern website today is analogous to downloading an exe.

Only 1/3 of this code is native to the website. 2/3 of the code loaded into the browser (tag management, analytics libraries, form builders, audio/video integration, social media, etc.) is fetched from a 3rd party. It is as if the web application is actually being “assembled” in real-time within the browser. Any changes in the code of the 3rd party component on a webpage could therefore alter the app's functionality. Given these profound changes in the architecture of modern web apps, what does it mean to secure the application and its users today?

Given the shift to client heavy frameworks for web applications, the server-side or in the network (such as a WAF), leaves you with no visibility into what the users of your web application are exposed to. With a substantial amount of code from 3rd party sites (static, dynamic or piggybacked scripts), you have no control over the code that is eventually running in the web browser. Further, a compromise of any of the 3rd party content that renders as "your website"  impacts the integrity of your web application and places your web users data at risk. Imagine a user, authenticated to a bank’s online site, suddenly being routed to a form asking her to re-authenticate with credentials, PIN, SSN, DOB, etc. An attacker has infiltrated this browser session.  Executing this request will route the form data to a server under the control of the malicious actor.  

These changes in web architecture have opened up avenues for JavaScript compromises (especially the ones coming from 3rd parties). These changes have created website and web application vulnerabilities that have been heavily exploited by recent attacks from groups such as MageCart. Rather than targeting each user individually,  attackers have targeted sites hosting shared components such as JavaScript libraries being fetched by the browser in real-time. This allows the attacker to significantly scale and attack since they can target any of the websites that are served this compromised code.   

Deepika Gajaria, Senior Director, Product Management

Deepika Gajaria, Senior Director, Product Management

Senior Director Product Management

Find Deepika on LinkedIn


Sign up for our Newsletter

Hand-picked security content for security professionals.