Slide 25 of 28
Part 4 · PreventionSlide 25
Slide 25 · MIT 07
Isolate third-party integration points — a compromised vendor response can’t reach the core API directly.
Architectural isolation as a last line of defense when technical controls fail.
The isolation approach

Rather than calling third-party APIs inline from core business logic, run integrations in dedicated adapter services with restricted network access and minimal permissions. The adapter processes the third-party response, validates and normalizes it, and passes only the safe, expected output to the core API. A compromise of the third-party or the adapter cannot directly affect the core API or database.

Inline integration (risky)
Core API calls third-party directly
Third-party response processed by the same process
Malicious response has direct access to core logic
SQL injection from response reaches the DB directly
One compromised vendor = core API at risk
Isolated adapter (safer)
Dedicated adapter service calls the third-party
Adapter normalizes, validates, and sanitizes the response
Only the validated, typed output passes to the core API
Adapter has read-only DB access (or no DB access)
Compromise reaches adapter only; core API is protected
Isolation in practice

In a microservice architecture, the isolating pattern is natural: each integration gets its own service with its own deployment, network policy, and permissions. In a monolith, isolation can be achieved with module boundaries and strict validation at the module interface. Even simple isolation — a dedicated class or function that handles all third-party API calls and returns typed, validated output — reduces the blast radius compared to inline processing of raw API responses throughout the codebase.

💼 Business takeaway

Ask your architecture team whether a compromised response from any third-party API could directly affect your core database or business logic. Good isolation means the answer is no — a compromised vendor reaches an adapter, not your core system.

← Back The matrix →