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.
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.