Notifications
Clear all
Topic starter
06/09/2026 5:18 pm
TL;DR: SOAP APIs still underpin high-value banking, healthcare, telecom, and government workflows, but LEVO argues they are disproportionately exposed to XML parser abuse, WSDL reconnaissance, and WS-Security misconfiguration, alongside broader API abuse trends including 681% growth in malicious API traffic and incidents affecting 95% of organisations. The security problem is not SOAP itself, but the gap between its criticality and the weaker governance, visibility, and testing most teams apply to it.
NHIMG editorial — based on content published by LEVO: Definition, Architecture & How SOAP Works in 2026
By the numbers:
- Malicious API traffic has risen by 681%, signalling a sharp increase in automated abuse pressure across exposed interfaces.
- 95% of organisations experienced at least one API security incident in the past year, showing that API exposure is now a mainstream operational risk.
Questions worth separating out
Q: What breaks when SOAP services are left exposed without contract governance?
A: Attackers gain a blueprint of operations, inputs, and endpoints through WSDL exposure, which makes reconnaissance and abuse far easier.
Q: Why do SOAP APIs become high-risk when they handle privileged workflows?
A: Because SOAP often fronts payments, claims, policy changes, and record access, a single control failure can produce immediate business impact.
Q: What do security teams get wrong about XML-based API protection?
A: They often focus on schema validation while underestimating parser behaviour, replay resistance, and signature binding.
Practitioner guidance
- Inventory every SOAP endpoint and WSDL Identify active, deprecated, and shadow SOAP services, then classify which ones still touch payments, records, or privileged workflow operations.
- Test WS-Security against real attack paths Validate signature wrapping resistance, replay protection, timestamp freshness, and element-to-signature binding using live requests rather than configuration review alone.
- Harden XML parsers and schema validation Disable external entities, cap recursion depth, constrain payload size, and verify that schema enforcement rejects malformed or oversized XML before the parser reaches backend logic.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- Schema-aware SOAP testing examples for XML injection, XXE, and signature wrapping
- Runtime visibility patterns for live SOAP traffic and deprecated endpoint discovery
- CI/CD pipeline integration details for continuous SOAP security testing
- Guidance on safer handling of legacy services that cannot be rapidly replaced
👉 Read LEVO's analysis of SOAP API security risks and testing priorities →
SOAP API security gaps: what practitioners need to fix now?
Explore further
06/09/2026 5:19 pm
SOAP security is really governance of legacy trust boundaries. SOAP persists because it protects business-critical workflows, but many teams still treat it as an inherited transport rather than a governed control plane. That creates a mismatch between operational importance and security investment. The lesson for practitioners is that legacy protocol status is not a reason to reduce control depth when the service still moves money, records, or privileged instructions.
A question worth separating out:
Q: How should organisations prioritise SOAP security in mixed API estates?
A: Start with the SOAP services that connect to regulated data, privileged functions, or deprecated business workflows. Those endpoints deserve discovery, contract review, parser hardening, and continuous regression testing before lower-value API surfaces. Prioritisation should follow business impact and exposure, not whether the service is old or widely understood.
👉 Read our full editorial: SOAP API security gaps persist in legacy systems and critical workflows
