Unveiling the Source: The Truth About Internal Web Risk Exposure

How much web risk do your own departments expose your business to? As a web exposure management company, Reflectiz is constantly working to detect and mitigate security threats for our clients, so our systems naturally amass huge amounts of web risk exposure data. This contains rich insights, and we’ve analyzed it to produce this cutting-edge report: The State of Web Exposure 2025, which you can get here, for free.

The report considered data from the top 100 websites (by visitor count) across various industries, and one big takeaway was that when it comes to web risk exposure, all departments are not created equal. Some functions present more of a risk exposure problem than others, and the report reveals that their relative contributions to overall risk exposure look like this:

Total risk exposure initiated by internal teams

As you can see, the IT department is the team most responsible for introducing vulnerabilities into systems that attackers could exploit, accounting for 37% of all cases. Second place goes to Marketing at 33%, with Digital next at 18%. The fact that IT-Security is responsible for any at all might seem like an eye-opener, but no department is infallible. It accounts for 9% of the overall risk exposure, while Compliance sits below 4%.

So, should everyone be asking those wizards of online safety in Compliance what their secret is? No, because we already know. It’s the fact that they don’t get to change as much code on a daily basis as the other departments. IT modifies the most website code, and Marketing is an understandable close second because they regularly implement integrations with third-party apps for things like customer tracking and analytics purposes.

The more freedom a department has to add and alter code, the more likely they are to introduce security loopholes. If Compliance were making as many regular changes, too, chances are they would be occupying the number one position instead.

This is all good to know because when you understand where the risks are most likely to come from, you can deliver more targeted risk awareness training to those departments and mandate safer practices.

Key to making this effective would also be an understanding of the nature of these risk exposure events:

Most critical risks

As the graphs above show, Marketing is the department most likely to allow applications to run in iframes for no good reason. IT has a much lower prevalence of this, but is much more likely to be accessing sensitive user inputs without justification and loading content from a public CDN.

The problem with iframes

IFrames, or inline frames, are like windows into another website or service. They’re HTML elements that allow your site to embed third-party features within a defined region of a page, things like video, audio, maps, social media widgets, and weather updates. This is great for adding functionality without having to create it, and they are entirely separate from the page, but they can expose it to security risks, including:

Cross-Site Scripting (XSS): Malicious scripts in an iframe can exploit vulnerabilities to steal user data or manipulate the parent page.

Clickjacking: Attackers can overlay invisible iframes to trick users into clicking malicious content and potentially execute unintended actions.

Cross-Origin Vulnerabilities: If not properly restricted, they can allow unauthorized access to the parent page’s data or resources via cross-origin requests.

Phishing and Malicious Content: Iframes can load untrusted third-party content, exposing users to phishing attacks or malware.

Frame Busting Issues: Without proper protections, attackers can manipulate iframe navigation to redirect users to malicious sites.

Resource Abuse: Iframes from untrusted sources may consume excessive resources, impacting performance or enabling denial-of-service attacks.

Whichever department is introducing iframes, you’ll need to ensure that various security measures are applied. These could include:

Using the sandbox attribute to restrict iframe capabilities.
Setting Content-Security-Policy (CSP) headers to control allowed sources.
Applying the X-Frame-Options header to prevent clickjacking.
Validating and sanitizing all external content.
Using srcdoc for static content instead of external URLs when possible.

In addition, the graph highlights the need to give the Marketing and Digital departments best practice training, so they understand that apps should not be running in payment iframes without a very good reason and a thorough risk assessment.

Accessing sensitive inputs (for no reason)

This is a ‘principle of least privilege’ issue. The graph above shows that IT staff had access to sensitive user inputs in more than a quarter of the organizations we looked at in the report. More people with unnecessary access means more potential points of failure. The fewer who have it, the better.

Anyone who can access sensitive data (like personal information, financial details, or protected health information) heightens the risk of insider threats, whether intentional (e.g., data theft) or accidental (e.g., mishandling). Access to plaintext or poorly encrypted data means it could be exploited if their accounts are compromised or if they fall victim to phishing or social engineering attacks.

GDPR fines alone can see you paying out €20 million or 4% of your annual global turnover, whichever figure is higher, so you’ll want to introduce the security recommendations that we mention in the report.

Loading resources from a public CDN

Content delivery networks offer script libraries, CSS, images, and more at speed, but some aspects of using public CDNs increase the attack surface.

A hacked or compromised public CDN can allow attackers to inject malicious code into the assets it serves (e.g., JavaScript libraries). This could lead to data theft, XSS attacks, or malware distribution across all websites using the CDN, including yours.

Then there’s the problem of third-party library vulnerabilities. Public CDNs often host popular libraries like jQuery, so if an outdated or vulnerable version is served, attackers could exploit known vulnerabilities to compromise your website.

A misconfigured or manipulated public CDN could serve altered or malicious content or simply issue an outdated and insecure version due to improper versioning.

Such problems are caused by IT departments in 95% of cases, so the best way to address them will be to focus your training and security efforts there.