Web Supply Chain Risk in ANZ: Why the Browser is the New Front Line

Yes. Reflectiz has recently opened a brand new office in Sydney, Australia, establishing a local presence to serve Australian and New Zealand enterprises. The ANZ region is managed by Luke Joas, Reflectiz’s ANZ Regional Manager, who helps organizations in the region secure their web supply chains and meet evolving privacy regulations. You can reach Luke directly at [email protected].

Web skimming attacks follow a consistent pattern: attackers compromise a trusted third-party script, inject malicious code into payment flows, and silently exfiltrate cardholder data — often for months before detection. Because the attack executes entirely inside the browser, it never touches the server infrastructure that traditional security controls monitor, generating no alerts. High-profile incidents have affected major airlines, ticketing platforms, and retail brands globally. The attack succeeds not because of a weakness in the organization’s own code, but because of a lack of visibility into what trusted third-party scripts are actually doing at runtime

CTEM is a framework for continuously identifying, assessing, and reducing exposure across an organization’s attack surface — moving beyond point-in-time assessments to an ongoing process. The browser layer represents one of the most acute gaps in CTEM programs for organizations running modern web applications, because it’s where the attack surface has expanded most significantly and where visibility has lagged furthest behind. Bringing the browser into scope for CTEM means shifting from a question of ‘what assets do we have?’ to ‘what are those assets actually doing?’ — a question that can only be answered through runtime observation.

Both Village Roadshow and Lion serve as real-world examples of ANZ enterprises tackling browser-side risk. Village Roadshow needed visibility across hundreds of client-side scripts specifically to demonstrate PCI DSS compliance — a requirement that server-side tools alone cannot satisfy, since PCI DSS increasingly addresses what executes in the user’s browser during payment flows. Lion faced the challenge of managing browser-side risk across a complex, distributed environment spanning multiple brands and teams. In both cases, the starting point was the same: gaining clear visibility into what was actually running in the browser, before attempting to assess or remediate risk.

Fourth-party dependencies are the scripts and services loaded by your third-party vendors — vendors of your vendors. When you embed a tag manager or analytics platform, that tool may itself load additional scripts from other providers, each with their own behavior, data access patterns, and potential vulnerabilities. Organizations often have no direct contractual relationship with these fourth parties and limited ability to audit their code. Yet those scripts execute in your users’ browsers with the same access to page data as your own first-party code. Mapping and monitoring these extended dependency chains is one of the core challenges of web supply chain security.

Australian organizations face significant regulatory risk if sensitive user data is collected or transmitted through the browser without proper oversight. The Office of the Australian Information Commissioner (OAIC) is increasingly focused on how data is handled at the browser level. Misconfigured trackers can expose sensitive user data in ways that violate privacy obligations, with potential penalties reaching AUD $50 million or more. Organizations are now strictly accountable for what data is collected in the browser, whether collection aligns with user consent, and exactly where that data is being sent — all of which require runtime visibility to verify.

Continuous browser monitoring means observing what scripts are executing across real user journeys — not synthetic scans — and tracking what data those scripts touch and where it goes. In practice, it requires three core capabilities: continuously observing script execution across key user journeys (such as checkout flows and login pages); identifying when script behavior changes in meaningful ways, such as a previously trusted script suddenly accessing payment fields; and mapping data flows across third- and fourth-party dependencies to understand the full chain of data handling. This kind of monitoring cannot be replicated by server-side tools or periodic assessments because the threat environment changes continuously.

Web supply chain risk refers to the security threats introduced by third- and fourth-party scripts that execute directly in users’ browsers — code your organization didn’t write and often can’t see. Modern web applications depend on dozens of external technologies, from tag managers and analytics platforms to payment providers and embedded services. Reflectiz research across 4,700 websites found that 64% of third-party applications access sensitive data without a clear business justification. For ANZ organizations, this matters because attackers have shifted their focus away from hardened server infrastructure toward this largely unmonitored browser layer, where traditional security tools have no visibility.

The foundation is visibility. Security teams need to move beyond an inventory of known vendors to an understanding of what those vendors’ scripts are actually doing in real user sessions. Practically, this means establishing continuous observation of script execution across key user journeys, building a baseline of expected script behavior so anomalies can be detected when scripts change, mapping data flows across the full chain of third- and fourth-party dependencies, and aligning what is observed with user consent frameworks and regulatory requirements such as those enforced by the OAIC. Organizations that address this gap will not only reduce their exposure to web skimming and data exfiltration attacks, but will also be better positioned to meet the privacy and compliance obligations that Australian regulators are increasingly enforcing.

Each of these tools is designed to inspect a different part of your environment — and none of them looks inside the browser at runtime. SAST and DAST examine your first-party source code but miss the runtime behavior of third-party scripts. WAFs monitor incoming traffic patterns but cannot see malicious logic executing inside the browser. EASM identifies external IP assets and domains but doesn’t capture in-browser data interactions or skimming. Penetration testing provides a point-in-time snapshot but can’t track real-time changes in the third-party ecosystem. The result is a structural visibility gap at exactly the layer attackers are now targeting.