Notifications
Clear all
Topic starter
06/09/2026 3:45 pm
TL;DR: SOAP and REST remain the two dominant API design patterns in enterprise environments, but their security risks differ materially: SOAP depends on contract enforcement and message-level controls, while REST expands faster and can sprawl without consistent authorization and visibility, according to LEVO. The practical question is not which style is safer in the abstract, but how governance, testing, and runtime monitoring keep pace with hybrid API estates.
NHIMG editorial — based on content published by LEVO: SOAP vs REST API testing, security, and architecture
Questions worth separating out
Q: How should teams secure SOAP and REST APIs in the same environment?
A: Use one governance model for discovery, testing, and runtime monitoring, then apply protocol-specific controls where needed.
Q: Why do REST APIs create more governance risk than SOAP in fast-moving environments?
A: REST changes faster, which makes undocumented endpoints, inconsistent scopes, and custom authorization logic more likely to slip past periodic review.
Q: What breaks when API authentication is correct but authorisation is weak?
A: Attackers can still read or modify data they should not reach, because identity was proven without proving entitlement.
Practitioner guidance
- Inventory SOAP and REST endpoints together Build a single authoritative inventory that captures business owner, auth method, transport, schema, and runtime exposure for both SOAP and REST services.
- Test authorisation at the object and operation level Add automated tests for broken object-level authorisation, overbroad scopes, and SOAP contract violations before release.
- Verify message-level controls where SOAP is used Check signatures, encryption, replay protection, and schema enforcement in the same pipeline, because partial WS-Security coverage creates a false sense of protection.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- A deeper walkthrough of SOAP testing workflows, including WSDL validation, XML schema checks, and WS-Security enforcement.
- Practical REST security examples covering token handling, authorisation logic, and the failure patterns that create API sprawl.
- Implementation guidance on monitoring, discovery, and runtime protection across mixed API estates.
- Use-case comparisons that help teams decide where SOAP remains appropriate and where REST is the better fit.
👉 Read LEVO's analysis of SOAP vs REST API security and testing →
SOAP vs REST API security , are your controls keeping up?
Explore further
06/09/2026 3:46 pm
API security has become identity security by another name: once APIs carry service credentials, OAuth tokens, and delegated access, the boundary between application security and IAM collapses. That means security leaders cannot treat REST sprawl or SOAP contracts as pure engineering choices. They are governance choices that determine how identity assertions, scope, and authorisation are enforced across the estate. Practitioners should align API governance with IAM ownership, not leave it isolated in delivery teams.
A question worth separating out:
Q: What should security teams do when SOAP and REST coexist in the same programme?
A: They should assign one control owner for API governance, one inventory, and one evidence model for reviews and audits. SOAP and REST can coexist safely, but only if access policy, monitoring, and testing are standardised across both. Without that, each protocol accumulates a different kind of blind spot.
👉 Read our full editorial: SOAP vs REST API security: what enterprise teams should weigh
