The so-called application supply chain — the network of interconnected and interoperable third-party components that modern applications increasingly rely on — represents one of the latest and most serious vulnerabilities that hackers are targeting. Security teams must rethink their approaches and strategies to respond to this threat.

Until only a few years ago, application developers employed a three-tier architecture or monolithic structure, hosting their apps in secure local data centers. In this straightforward model, applications were simple to build and deploy, and the application perimeter was easy to define and protect. Enterprises largely did (and continue to do) a good job protecting their data centers, safeguarding their single-entry point with an application delivery controller and a web application firewall (WAF).

Today, due to newer application architectures, security has gotten a lot more complicated. Now, enterprises create, maintain and host multiple applications in multiple environments (e.g., on-premises and in the cloud), and rely on many connections to third-party services to feed content and data into the applications. The average application depends on dozens of third-party JavaScript services to support processes related to areas such as inventory management, advertising, payment services, and numerous other widgets and content sources. Some examples of popular JavaScript services include brands like Google Analytics, Outbrain, WordPress, Magento and Tranzila. Many of these application components even use a series of fourth- and fifth-party subcomponents and services.

With a substantial portion of the content now composed by the user’s browser (instead of a web server safely protected behind the WAF), this application supply chain represents a significant and tempting vulnerability to hackers and other nefarious actors.

As threats escalate, we see many organizations employing multiple WAFs for their different environments, as well as solutions to prevent and respond to DDoS events, malicious bots, API hacks and other attacks on the application’s main digital assets and data centers. Unfortunately, in the new model of the application supply chain, these go-to methods, tools, and practices are no longer enough to protect an application’s data.

Formjacking: A new opportunity for hackers

As server-side security matures, more hackers are on the hunt for new entry points, including the often-overlooked third-party services and connections in an applications infrastructure. From here, they’re launching attacks through the less protected and monitored client-side supply chain. One of the fastest-growing threats for exploiting vulnerabilities in the application supply chain is formjacking. In this attack, sophisticated attackers hide malware in third-party services used by the application.

When a user receives an HTML response from the app to initiate a form request to the infected third-party service, in response, malicious code is injected directly onto the target’s form. It collects the sensitive information the user enters and returns it to the attacker’s remote server — outbound traffic that’s not monitored by the WAF. Unfortunately, in addition to going to the intended payment service (for example), the user’s personally identifiable information (PII) is unknowingly redirected to the hacker’s server.

Real world consequences

Executed successfully, attacks on the application supply chain can have devastating results.

In 2018, hackers used formjacking to collect payment-card data from 380,000 British Airways customers by adding scripts on the baggage claim information page of the airline’s website – which then collected data from visitors and sent it back to the hackers’ server.

In addition, thieves attacked Segway in 2022 to skim credit card information from hundreds of thousands of customers by inserting scripts into Segway’s vulnerable online stores. Cybersecurity experts believe the hackers targeted a vulnerability in the content management system the store uses. In California in 2022, a single formjacking attack on a third-party plug-in led hundreds of restaurant websites to lose tens of thousands of customer records. In January 2023, there was a huge formjacking attack on one of Canada’s biggest beverage retailers.

Traditional WAFs: A weak link

Despite an organization’s best efforts to protect their application environments and customers’ personal data, the information their users enter on the browser side (e.g., ID numbers, addresses, or credit card numbers) can be exposed to third-party services embedded in their applications. These are automatically trusted by the main application but are rarely monitored. And that becomes the organization’s problem. The organization is liable for data breaches on the browser side of their application just as much as on the server side in their data center.

Traditional WAFs monitor only incoming traffic to applications — the data path between end users and the application. Since the WAF is deployed as an on-prem appliance or as a reverse proxy cloud WAF, it’s blind to any communication between the user’s browser and the application’s third-party services. Nonetheless, regulators will hold the organizations responsible for the safety of its users’ data and PII. But that presents a major problem—a few important things are simply out of an organization’s control:

• There’s no way to know if the JavaScript code in the services its applications rely on has been breached or tampered with.
• It has no control over the security of third-party services.
• It cannot monitor the subcomponents — the fourth- or fifth-party services — its applications rely on.

Protection from the client side

Client-side protection is the key to protecting user data and accounts while conforming to compliance frameworks.  But what should an organization look for in a solution?

• Visibility — An organization can’t address what it can’t see. But in many organizations, the people who are securing the application aren’t necessarily aware of all the potentially dozens of third-party services and platforms in use. That’s why it’s essential to find a client-side protection tool that can automatically detect, map, and expose all third-party services in the application supply chain.
• Change Detection — Client-side protection is only valuable if it’s up to date. Make sure the protection solution continuously detects changes and sends alerts any time a component in the supply chain gets updated. In particular, be on the alert for unusual communications or illegitimate script parameters between users’ browsers and the application’s third-party services.
• WAF Integration — A client-side protection tool should be a seamless part of the WAF, so it can mitigate and block anomalous and nefarious requests and prevent data leakage.
• Granular Mitigation — Since most of the third-party JavaScript services in the supply chain are vital to an application’s functionality, a client-side protection solution must be able to surgically block only the nefarious scripts without taking down entire services.

Trust but verify

In general, enterprises do a fine job of protecting their data centers. That’s why hackers are looking for new and easier ways to attack applications or steal information. Modern applications are increasingly reliant on third-party services and plug-ins. And the content for today’s applications primarily happens in the browser. That means many more opportunities for malicious actors who can plant malware in one third-party service — and attack many sites all at once.

While most third-party vendors work constantly to patch and update their services, the ultimate responsibility for the security of an application will still fall to upon the organization. That’s why it’s essential for organizations to be vigilant in their efforts to verify the legitimacy and security of the third-party components connected to their applications.