Modern applications are not self-contained programs — they are collections of calls to APIs a company does not own, does not control, and often does not even inventory. A checkout flow calls a payments API. A dashboard calls a weather API, a maps API, a fraud-scoring API, and a third-party analytics API before it finishes rendering. Every one of those calls returns data that gets stored, displayed, or executed inside your application with far less scrutiny than the input your own users submit through a form.
That double standard has a name: OWASP calls it "Unsafe Consumption of APIs," and it became the tenth entry in the 2023 API Security Top 10 for a reason — attackers have repeatedly shown that the fastest way into a hardened application is through the third-party data pipe nobody thought to validate. From the Polyfill.io script that turned 100,000+ websites into malware distributors in June 2024, to the 3CX supply chain attack that cascaded through two separate companies in March 2023, the pattern keeps repeating. This post breaks down why it happens and what actually stops it.
What Is "Unsafe Consumption of APIs" in OWASP's Top 10?
It is API10:2023 — the entry OWASP added when it refreshed the API Security Top 10 in 2023 — and it inverts the usual threat model. Instead of warning developers to distrust their own users, it warns them to stop unconditionally trusting everyone else's API. OWASP's own writeup describes the pattern plainly: teams apply rigorous input validation, size limits, and sanitization to data coming from end users, then apply almost none of that discipline to data coming back from a partner or third-party API, because "it came from our own integration, not a random user."
In practice that shows up as: skipping TLS certificate validation on outbound calls, following redirects without checking the destination, accepting oversized or malformed payloads because "we trust them," and — the most damaging version — piping a third-party API's response directly into a database query, a shell command, or an HTML template with no escaping. OWASP's reference scenario is a data-enrichment integration where an attacker compromises the upstream API (or intercepts it via a stale TLS config) and injects a payload that later fires as stored XSS or SQL injection inside the consuming app's own environment. The vulnerability lives in your code, but the trigger lives in someone else's API.
How Did Polyfill.io Turn a Trusted Script Into Malware for 100,000+ Sites?
It happened because ownership of a widely embedded domain changed hands and nobody who depended on it noticed. In February 2024, a company called Funnull acquired the polyfill.io domain and its associated GitHub account from the original maintainer. The polyfill.io service had been embedded for years via a single <script src="https://cdn.polyfill.io/..."> tag on well over 100,000 sites, including major consumer brands, as a way to backfill missing JavaScript features in older browsers.
By June 2024, researchers at Sansec discovered the domain was serving injected malware — redirecting mobile visitors to sports-betting and adult sites, and selectively withholding the malicious payload from IP ranges associated with security researchers to evade detection. Cloudflare and Fastly moved within days to stand up clean mirrors so sites could swap the domain without rewriting code. The root failure was not a coding bug; it was that thousands of engineering teams had wired a live, third-party-controlled endpoint into their production pages with no integrity check — no Subresource Resource Integrity hash, no pinned version, no monitoring for a domain-ownership change — and simply consumed whatever it returned, indefinitely.
Why Did the 3CX Attack Cascade Through Two Separate Companies?
Because 3CX consumed a trojanized third-party application the same way its own customers later consumed 3CX's trojanized update — without any independent verification of what they were pulling in. Mandiant's investigation, published in April 2023, traced the incident back to a 3CX employee who had installed a compromised version of Trading Technologies' X_TRADER software on a personal computer used for work in 2022. That single act of unsafe consumption gave North Korea-linked attackers a foothold that eventually reached 3CX's build environment.
From there, attackers compromised 3CX's software supply chain and shipped a trojanized version of the company's Electron-based desktop VoIP application — used by more than 600,000 companies and roughly 12 million daily users — through 3CX's own legitimate update mechanism starting around March 2023. Security researchers labeled it the first publicly documented case of one software supply chain attack cascading directly into a second. Every victim in the chain did the same thing: pulled in an external binary or update because it arrived through a channel that looked authoritative, with no independent check on whether that channel had itself been compromised.
What Happened When Codecov's Upload Script Was Silently Modified?
Attackers altered Codecov's Bash Uploader script on the company's own hosting infrastructure, and roughly 29,000 customer CI pipelines executed the tampered version for about two months before anyone noticed. Codecov disclosed in April 2021 that the breach had started on January 31, 2021, after attackers exploited an error in the company's Docker image creation process to extract credentials that let them modify the script undetected.
The mechanism is the purest form of unsafe API/service consumption: customer build pipelines fetched the script with a curl | bash-style pattern and executed it directly inside CI environments, with no hash verification against a known-good version. Because CI environments routinely hold cloud credentials, signing keys, and internal API tokens, the compromised script was able to harvest and exfiltrate secrets from every environment that ran it — turning a one-line convenience integration into a mass credential-theft pipeline. Codecov's incident, alongside the 2018 npm event-stream/flatmap-stream compromise that targeted a Bitcoin wallet's dependency tree, shows the failure isn't unique to REST APIs — it's any external artifact pulled in and trusted by default.
How Much Has Blind API Trust Actually Cost the Industry?
The scale is large enough that analysts flagged the trend years before these specific breaches landed. Gartner warned in 2021 that by 2022, API abuses would move from an infrequent to the most frequent attack vector against enterprise web applications — a prediction that tracked closely with what followed. Salt Security's State of API Security Report for Q3 2021 found that malicious API traffic grew 681% that year while overall API traffic grew only 321%, and that 95% of surveyed organizations had experienced some form of API security incident in the preceding twelve months.
Those numbers describe outbound-facing API risk, but the consumption side compounds it: every API a company calls is another organization's attack surface becoming, transitively, your own. A vendor that gets breached, a domain that changes hands, a build pipeline that gets compromised — none of it shows up in your own vulnerability scans, because the vulnerable code never lived in your repository. It lived in a response payload you trusted.
How Safeguard Helps
Safeguard treats every third-party API and external dependency your systems call as part of your attack surface, not outside it. Instead of assuming a partner integration is safe because it has always been safe, Safeguard continuously inventories the external APIs, scripts, and services your applications actually consume — including ones added ad hoc by individual teams that never went through a formal review — so you have a real answer to "what are we trusting, and since when?"
On top of that inventory, Safeguard monitors for the specific conditions that turned Polyfill.io, 3CX, and Codecov from routine integrations into breaches: unexpected domain-ownership or certificate changes on services you depend on, unpinned or unverified third-party scripts and packages pulled into build and runtime environments, and anomalous behavior in data returned from upstream APIs that doesn't match established baselines. Combined with software composition analysis and build-pipeline integrity checks, this gives security teams the same rigor for what comes in from partners and vendors that they already apply to what comes in from end users — closing the exact gap OWASP codified as API10:2023, before an attacker finds it first.