Web Exposure Webinar With Integrity360 – Watch Now

Why Web Exposure Matters

Integrity360 is Europe’s leading independent payment compliance and cybersecurity service provider, and Reflectiz CEO Idan Cohen recently joined staff members Rich Ford, Stephan Engelke, and Fabrizio Cassoni for an in-house ‘fireside chat’-style webinar. The subject was web exposure, a crucial, yet relatively underexplored area for many, including even the host at one time, apparently. Rich confessed that he was naïve about the scale of the problem until the 2018 Magecart attack on British Airways brought it to his attention.

If you’re equally in the dark on the subject, don’t feel bad. As this free-ranging discussion reveals (and you can watch it here), the concept of web exposure doesn’t quite fit with the traditional way many of us look at threats.

Why Traditional Threat Frameworks Fall Short

As Fabrizio noted, frameworks such as MITRE ATT&CK, CBSS, or Microsoft STRIDE are not well-suited to describing web exposure threats because they fail to precisely encapsulate the nature of the problem, which is where it happens. The key issue is that these traditional frameworks are designed around vulnerabilities and attacks that take place within a controlled infrastructure, whereas web exposure occurs outside the defender’s direct control, in the user’s browser, and through third-party scripts. While these threats might be loosely mapped to existing categories like input capture or session hijacking, they don’t fundamentally describe the core problem of third-party script risks and runtime manipulation of web content.

A Shift in the Security Paradigm

It’s a problem of perspective that Idan outlined by contrasting the normal software development lifecycle with introducing third parties to a website. Normal software development involves stages like planning, coding, production, and review, but inviting third parties into your infrastructure via code snippets and pixels changes that paradigm, because they can potentially gain full access and make changes to your production website, without you even knowing about it.

Fabrizio made the point that in this scenario, it can be hard to know who bears the responsibility for protection, which brings to mind the old Russian saying, ‘Trust but verify.’ During America’s nuclear disarmament discussions with the Soviet Union, President Ronald Reagan grew fond of using it in relation to each side checking the other’s compliance with the agreement. Trust but verify says, we trust you, but we’re going to check you’re being honest.

Website owners would do well to think in the same way towards third-party applications, code, and pixel providers. You’re perfectly welcome to trust your third-party vendors, but it’s in your best interests to continuously verify that they haven’t been compromised by malicious actors or misconfigured in a way that makes them leak sensitive data or weakens them, because of the access that they have to your systems.

 Watch the full web exposure webinar here.

Outsourcing Functionality Means Accepting Built-In Risk

On occasion, Reflectiz customers have expressed surprise and concern to Idan when Facebook changes their website code, but rather than try and fight Facebook, he thinks they need to shift perspective and accept that vulnerability is a feature of outsourcing functionality rather than a bug.

When you permit a third party to add features, it’s best to do so in the full knowledge that there’s an element of compromise built into the arrangement. You willingly accept that, by design, using the Facebook pixel introduces vulnerability to your website’s infrastructure. As Idan explained for the benefit of webinar audience members, pixels may appear to be small images, but they actually contain lines of JavaScript code that developers place on websites. Due to the nature of web architecture, once a script is added, this third-party code gains full control of the site and can modify it. That doesn’t necessarily mean that there’s anything malicious about Facebook, TikTok, or any other third-party provider, though, just that there is now a risk element that you need to manage.

The Hidden Power of JavaScript and Pixels

We should say ‘risk elements’, plural, because, by design, JavaScript can perform various actions like logging keystrokes, redirecting users to malicious sites, or collecting user data, all without hacking the website. These capabilities just happen to be inherent to JavaScript’s functionality. So, when a marketing team wants to add a tracking pixel for a campaign, the third-party script can potentially access and manipulate all website content, not just perform its intended tracking function.

It’s this level of access that attracts cybercriminals, because if they can gain access at the JavaScript level, they can effectively gain the keys to the entire kingdom. But even without malicious actors, you still need to account for human error. Pixels get added or changed all the time, and somebody is guaranteed to misconfigure one eventually. When that happens,  the pixel may accidentally gain permission to collect more personal, health, financial, or whatever data than it should, the data flows outward, and you have an accidental breach that GDPR, PCI DSS, HIPAA, or whoever can still fine you for.

The Case for a Truly Proactive Approach

The way to reduce web exposure is through inventory building and continuous monitoring. When Reflectiz scans a website it builds a full inventory of all the third parties (and even any third parties that they may use), by mimicking the behavior of an ordinary browser ‘in the wild’ so that it replicates the typical user’s environment which is outside of your WAF, and beyond your control. The WAF doesn’t sit between the user and the web server, so that’s the space Reflectiz occupies. It loads resources directly from GitHub or CDNs as they do, and with this approach, it can see which scripts and pixels are accessing what data, where they are trying to send it, and alert you if they don’t have explicit permission to collect it and send it there.

When we talk about being proactive in managing web exposure, it’s important to understand that we’re not just looking for vulnerabilities in the traditional sense. A lot of the security ecosystem is focused on discovering CVEs, patching them, and moving on. And that’s not a bad thing — finding vulnerabilities and closing them is necessary. But Idan believes there’s another critical layer of protection: being proactive means going beyond just searching for vulnerabilities.

We’re not always looking for an obvious breach or malicious code or even a specific misconfiguration. Instead, we need to create and maintain a detailed inventory of digital assets, especially third-party and open-source components running on a site. Today, there are tools that can automatically analyze and identify the risks associated with those components.

For example, you might be using a fantastic open-source library, but it’s hosted on an open server or a CDN where anyone can make changes. It may not pose a risk today, but can we guarantee that in six months, it won’t be compromised? That’s the kind of long-term risk potential we need to anticipate.

The proactive approach isn’t about waiting for an alert to trigger because malicious behavior was detected. It’s about understanding your environment well enough to anticipate and reduce risks before they turn into threats. If you know what scripts are running, what third parties are involved, and how those scripts behave, you can take preventive action.

 Watch the full webinar HERE.. 

The Power of Good Housekeeping

One of the key alerts Reflectiz provides today is when a script loads from a remote server on your login page. Login pages are highly sensitive — they contain user credentials and other valuable data. Idan recommends never loading third-party scripts directly on sensitive pages. If you must use third-party code, host it yourself, on your own server, so you can monitor and control it. 

Often, when Idan speaks with CISOs and asks them what scripts are running outside their environment, they don’t even know. No one is really tracking that today, and that’s exactly why inventory is so important. If you must use tracking pixels or analytics scripts, use them with strict privilege controls. Platforms like TikTok or Facebook offer dashboards where you can choose what kind of data they’re allowed to collect, so the message is, use them to whitelist only what’s absolutely necessary.

Reflectiz has seen cases where companies unknowingly sent credit card data to third parties — not because the third party was malicious or changed its code, but because the settings were configured to “collect everything.” Even if your page doesn’t have sensitive data today, marketing might later add a form with passwords or credit cards, and suddenly, you’re leaking sensitive information.

So again, this is what being proactive really means:

1.  Build and maintain an accurate inventory of your scripts and third-party tools.

2.  Remove anything unnecessary or leftover.

3.  Use scripts in the correct places, with the right settings.

4.  Restrict access to sensitive areas and limit privileges.

That way, even if something goes wrong — even if good code becomes malicious — the impact is minimized. If that code only runs on a marketing page with no sensitive data, the risk is low. But if it’s running in your production environment with user accounts and financial data, you’ve got a serious problem.

And by the time you get an alert that the code has changed, it may already be too late — the data is already leaking. Don’t wait for the vulnerability to appear. It will happen eventually — that’s just the reality of cybersecurity. Your job is to reduce the risk before it does. For more valuable insights, watch the full discussion here.