Use one governance model for discovery, testing, and runtime monitoring, then apply protocol-specific controls where needed. SOAP should be validated through contract and message security checks, while REST needs continuous endpoint discovery, object-level authorisation testing, and token governance. The main goal is consistent assurance across both styles, not separate security programmes.
Shared API Governance for Two Different Failure Modes
SOAP and REST often sit behind the same gateway, IAM stack, logging pipeline, and CI/CD process, but they fail in different ways. A shared governance model matters because teams otherwise secure the transport or the framework and miss the object, message, or contract layer where abuse actually happens. For broader API governance and lifecycle expectations, the OWASP API Security Top 10 remains a useful reference point, especially where discovery and authorisation failures cross both styles. OWASP API Security Top 10
The practical mistake is treating SOAP as “legacy and therefore static” while treating REST as “modern and therefore dynamic.” In reality, SOAP services can expose high-value operations through stable but deeply privileged contracts, while REST services can accumulate shadow endpoints, inconsistent object checks, and token sprawl. Security teams need a single view of inventory, ownership, testing evidence, and monitoring thresholds so that a control gap in one protocol does not become the blind spot for the whole environment. In practice, many security teams discover this only after one API style has already been validated more rigorously than the other.
How SOAP and REST Controls Differ in Daily Operations
Securing both styles in the same environment works best when teams separate governance from enforcement. Governance should answer who owns the API, what data it can touch, how it is tested, and what telemetry proves it is still behaving as intended. Enforcement then adapts to protocol mechanics. SOAP usually depends on formal contracts, strict schema validation, and message-level protections where sensitive operations are embedded in a small number of documented actions. REST usually depends more on endpoint discovery, resource-level authorisation, token scope review, and consistent handling of verbs, path parameters, and object identifiers.
A good operating model usually includes:
- A single inventory of services, owners, consumers, and critical operations.
- Contract and schema checks for SOAP, including rejection of unexpected actions or malformed envelopes.
- Endpoint enumeration and object-level authorisation testing for REST, including checks for insecure direct object references.
- Shared token and secret governance so authentication does not drift by protocol or by team.
- Runtime logging that can correlate traffic back to the service owner, caller identity, and operation name.
For REST-specific guidance, OWASP’s API Security Top 10 is useful because it highlights common authorisation and discovery failures that contract-only reviews miss. SOAP, by contrast, tends to break when teams assume the WSDL is enough and do not validate the actual message processing path. The environment is strongest when testers can prove that both protocols are covered by the same policy intent, even if the technical checks differ. This guidance breaks down when teams have no reliable service inventory, because then neither SOAP contracts nor REST endpoint scans can be trusted to represent what is actually exposed.
Where Mixed API Environments Usually Drift
Tighter API control often increases testing and ownership overhead, so organisations must balance consistency against the reality that SOAP and REST age differently across the estate.
The biggest edge case is governance drift between “approved” and “actually live” interfaces. Teams sometimes maintain strong controls on documented SOAP services while REST endpoints proliferate through newer applications, partner integrations, or internal tooling. Another common variation is partial trust in gateways: a gateway may standardise authentication, but it cannot by itself prove that the backend is enforcing object-level authorisation or that the SOAP processor is rejecting unsafe message patterns. Guidance-vs-consensus is also relevant here. There is broad agreement that discovery, authentication, and monitoring are necessary, but there is less consensus on whether a single testing harness can fully cover both protocols without protocol-specific test design.
Mixed environments also create a false sense of parity. SOAP may appear more controlled because it is contract-driven, while REST may appear simpler because it is JSON-based and easier to instrument. In practice, the risk is asymmetrical: SOAP often concentrates privilege in fewer operations, while REST more often spreads exposure across many paths and objects. Teams should therefore treat “same environment” as a governance statement, not a claim that the controls can be identical.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Mixed API estates often rely on tokens, service identities, and owned integrations. |
| Recommendation: Track API-linked identities and secrets so SOAP and REST consumers can be governed consistently. | ||
| CIS Controls v8 | 6 | SOAP and REST security both depend on enforcing access by service, user, and object. |
| Recommendation: Define and enforce access consistently across API endpoints and operations. | ||
| MITRE ATT&CK | T1190 | Exposed SOAP and REST APIs are common public-facing attack surfaces. |
| Recommendation: Treat exposed APIs as attack surfaces requiring testing for abuse and unauthorised access. | ||
| NIST CSF 2.0 | PR.AC | The question centres on access governance across API types. |
| Recommendation: Apply consistent authentication and authorisation governance across both API styles. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 | REST object-level auth and SOAP operations both fail when privilege is too broad. |
| Recommendation: Use least privilege for API calls and verify object-level authorisation outcomes. | ||
Practitioner Guidance
What to prioritise: build one asset and ownership model first, then prove that each API style has its own validation coverage. If the inventory cannot distinguish SOAP operations from REST resources, the rest of the control stack will be hard to trust.
What to verify: confirm that REST testing includes object-level authorisation checks, not just authentication and happy-path endpoint tests, and confirm that SOAP validation exercises the actual message-processing path rather than only the published contract. The control should fail closed when unexpected operations, objects, or message structures appear.
Common mistake: teams often assume gateway policy means backend policy. That assumption is usually wrong whenever a downstream service interprets SOAP actions differently from the edge, or when REST backends expose objects that the gateway cannot meaningfully authorise on their own.
Practitioner takeaway: the safest mixed-environment pattern is one governance layer with protocol-specific verification, because the real failure is rarely “SOAP versus REST” and more often “shared policy with uneven proof.”
Related resources from NHI Mgmt Group
- How should security teams govern MCP servers that wrap REST APIs?
- How should teams secure data at rest without relying on encryption alone?
- What should teams do when a developer environment can call hidden or undocumented APIs?
- How should security teams secure APIs that rely on machine-to-machine credentials?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
