Shift in Web Architecture and its Impact on Security

Fifteen years ago, when a user visited a website, all the logic and processing happened on the server, and the client device received mostly HTML. 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.

First, 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 apps needed to work offline or in a disconnected mode. Second, companies like Google wanted users of their cloud hosted applications, such as Google Docs, to have the same experience of working on Microsoft Office on their desktop. If any changes were made to a spreadsheet, all computations took place locally instead of making round trips to the web server.

As a result of these two key developments, many modern web apps use client heavy frameworks such as Angular, Ember, React, Backbone etc. When a user visits a website, the browser loads a lot of JavaScript from the site and executes that code on the client. It is fair to say that the browser is now 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 is analogous to downloading an exe.

In addition, only 1/3rd of this code is native to the website. 2/3rds of the code loaded into the browser (tag management, analytics libraries, form builders, audio/video integration, social media ..) 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, protection on 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 your 3rd party component’s site impacts the integrity of your web application and its users. Imagine a user, authenticated to her bank’s online site, suddenly sees a form asking her to re-authenticate with credentials, PIN, SSN, DOB etc. When she presses the Submit button, the form data is not going to the bank’s website but somewhere else (such as a Zeus botnet IP).

In conclusion, the changes in web architecture have opened up avenues for JavaScript compromises (especially the ones coming from 3rd parties) are what have been heavily exploited by recent attacks from groups such as MageCart. Rather than targeting each user individually, these hackers have targeted sites hosting shared components such as libraries being fetched in the browser in real-time. This impacts many more users not just of one website but those of hundreds of websites that use the same shared component.


Magecart PCI Advisory on CSP

by admin

An important update from the Payment Card Industry Security Standard Council was issued August 1st defining a set of recommendations […]

read more


Tala is powered by advanced AI and threat intelligence.

Get the most comprehensive view into how your users are being attacked. Understand the where, how and when of attacks, in real-time. Tala’s AI driven analytics helps you focus on attacks that matter the most.

download now

Request A Demo

Learn how Tala’s technology works and can help you protect your users against malicious attacks.