Treat the anti-corruption layer as a trust boundary. Validate everything that crosses it in both directions, give it narrow credentials, log translations, and scan it like any other service. It exists to keep legacy semantics out of the new design, so it must not pass legacy weaknesses through.
What the layer does
Microsoft's guidance describes the anti-corruption layer as a facade or adapter between subsystems that do not share the same semantics. It translates requests from one to the other, so the new application is not forced to adopt legacy APIs, data models or protocols. The strangler fig guidance recommends it for calls between migrated and unmigrated parts.
That makes it a natural place for security controls, and a natural place for bugs, since translation code is custom and sees data from both worlds.
Threats at the layer
- Injection through translation. Legacy fields may contain unescaped content, and the layer forwards it to a modern service that trusts its input.
- Privilege confusion. Legacy roles map poorly to new permissions. A lazy mapping grants too much.
- Credential sprawl. The layer often holds credentials for both sides.
- Old protocols. It may speak outdated formats and use libraries that parse them, such as XML or binary readers, which are common sources of vulnerabilities.
Controls
- Validate on both sides. Define a strict schema for what the new service accepts, and reject anything outside it. Do the same for responses going back to legacy.
- Map roles explicitly. Keep a written table from legacy roles to new permissions, reviewed by the owners of both systems.
- Use separate narrow credentials for each side, stored in a secrets manager.
- Limit network paths. The layer should reach only the systems it translates between.
- Log every translation decision with request identifiers, without logging sensitive payloads.
- Scan its dependencies. Parsers for old formats deserve extra attention.
- Give it an expiry. Record the planned removal date. A layer built for migration should disappear with the legacy system.
| Risk | Control |
|---|---|
| Bad input flows through | Schema validation both ways |
| Role over granting | Written, reviewed mapping |
| Stolen credentials | Per side secrets, short lifetime |
| Forgotten after migration | Removal date and owner |
Keep it small
The more logic the layer holds, the more it becomes a second monolith. Keep it to translation. Business rules belong in the new services. A small layer is easier to review and to retire.
Test it
Write tests that send malformed legacy payloads and unexpected role values through the layer. Include cases the legacy system never produced but an attacker might. Run these in CI on every change.
Safeguard's dependency scanning and reachability analysis can cover the libraries inside the layer, and its policies can gate pull requests that add vulnerable parsers. For wider context see legacy software supply chain risks.
Quick check
Is the anti-corruption layer the same as an API gateway?
No. A gateway handles cross cutting concerns like routing and authentication. The layer translates between different semantics. They can be combined, but the jobs differ.
When should it be removed?
When the last legacy dependency is gone. Set that expectation from day one.
Sources
- Anti-Corruption Layer pattern, Azure Architecture Center
- Strangler Fig pattern, Azure Architecture Center
Last reviewed: 19 October 2026.
