Slide 19 · MIT 01
Treat third-party API responses as untrusted input — the same as user-submitted data.
The source of data does not determine its trustworthiness for security controls. The context of use does.
The mental model shift
Current (vulnerable) mental model: “This data came from Stripe / Google Maps / GitHub, so it’s safe.” Correct mental model: “This data is going into a SQL query / HTML template / log statement. It must be treated as potentially malicious regardless of source.” Security controls belong at the point of use, not at the point of trust.
User input → validate → parameterize → escape
Third-party response → skip validation → use directly
“It’s from a trusted API” = exempt from controls
Fails when the trusted API is compromised
Any value → going into SQL? → parameterize
Any value → rendered as HTML? → escape
Any value → going to the logger? → strip dangerous patterns
Source is irrelevant to the control applied at use
Practical implementation
The practical change is in code review and security testing. Threat models must include: “What if this third-party API returns a malicious value in field X?” Integration adapters must be reviewed with the same scrutiny as user-facing handlers. SAST rules that flag unparameterized queries or unescaped output must apply to all code paths — including those fed by third-party API responses. Write integration tests that pass adversarial values (SQL injection strings, XSS payloads, JNDI strings) as mock third-party responses and confirm they are handled safely.
💼 Business takeaway
Ask your team: when data comes back from a third-party API you integrate with, does it go through the same validation as data submitted by your own users — or does it skip that step because “we trust the vendor”? The Ticketmaster breach happened because the second assumption was wrong.