API10:2023 — Unsafe Consumption of APIs

Slide 17 · The Pattern

Three scenarios, one failure: security controls were scoped to user input — not all untrusted data.

The common thread across every API10 scenario.

The API10 pattern

In every API10 scenario, a security control existed — parameterized queries, SSRF validation, XSS escaping — but was applied only at the user-facing boundary. Data entering the system through a third-party integration took a different code path that was exempt from these controls. When a third-party was compromised or returned unexpected data, the exemption became the vulnerability.

🛡️

Security controls are applied at the wrong boundary

The correct mental model: security controls should be applied at the point where data is used, not at the point where it enters the system. Parameterization belongs in every SQL query — regardless of where the value came from. Output encoding belongs in every HTML template — regardless of whether the data came from a user or a third-party.

🔗

Third parties extend the trust boundary — but not the security perimeter

Integrating a third-party means trusting their service to do what it advertises. It does not mean trusting that their output will always be safe for SQL queries, HTML rendering, or log processing. Vendor security incidents, CDN compromises, and supply chain attacks are real and recurring. The security perimeter must extend to include all data, regardless of source.

📋

The fix is context-driven, not source-driven

Whether to escape HTML should depend on whether the data is being rendered as HTML — not on where the data came from. Whether to use parameterized queries should depend on whether the data is going into a SQL statement. Treat third-party data exactly as you treat user input: validate at ingestion, sanitize at use, escape at output.

← Back Prevention →