Security controls — input validation, sanitization, output encoding — are applied at the API’s external boundary: the endpoints that receive requests from users. Data that enters through third-party integrations takes a different code path — one that was never reviewed for injection risks because it was considered internal, not external.

Integration adapters are often written to “just make it work” and then forgotten. Threat models focus on what an attacker can send to the API — not on what a compromised third-party might return to it. Penetration tests target the API’s external surface. Nobody tests what happens if the geolocation API returns SQL in a city name.

The threat model “what if our payment processor is compromised and starts returning malicious data?” is uncomfortable to model because it implies distrusting a business partner. Teams focus on threats they can control. Supply chain attacks are external to the organization and feel like someone else’s problem — until they aren’t.

Third-party API responses are assumed to be stable. There is no alert for “the response from this endpoint changed significantly” or “this CDN file changed since yesterday.” A compromised third-party can modify responses gradually or suddenly — with no automatic detection by the consuming API.

Developers often conflate “secure connection to the third-party API” with “the data from the third-party is safe.” TLS ensures the response came from the expected server without being modified in transit. It says nothing about whether the server itself has been compromised or whether the response data is safe to process without validation.