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.
At a glance
What this is: SOAP APIs remain deeply embedded in high-value enterprise workflows, and the article argues that their security gap comes from legacy complexity, exposed contracts and weaker governance than modern REST estates.
Why it matters: IAM, PAM and API security teams should treat SOAP as a high-risk control surface because misconfigured authentication, authorization and message protection can expose regulated transactions and sensitive records.
By the numbers:
- Malicious API traffic has risen by 681%, according to LEVO.
Context
SOAP remains a live governance problem because many organisations still rely on it for regulated, high-value workflows that cannot simply be rewritten away. In practice, the risk is not that SOAP is obsolete, but that older services often sit outside the visibility, testing and ownership models applied to newer APIs.
The security issue is therefore a control gap between business criticality and security attention. Where SOAP endpoints carry financial, clinical or identity data, weak authentication, exposed WSDLs and parser misconfiguration become access and integrity risks that cross both application security and identity governance.
This pattern is typical in legacy estates that were modernised around the edges while the original SOAP layer stayed in production. The article’s warning is that the long tail of interface debt is now a security debt as well.
Key questions
Q: What breaks when SOAP services keep exposing WSDL contracts publicly?
A: Public WSDL exposure shortens attacker reconnaissance by revealing operations, schemas and endpoints in advance. That makes it easier to target high-value methods, craft valid-looking requests and identify where authentication or authorization gaps are most likely to matter. Teams should treat WSDL exposure as a governance issue, not just documentation hygiene.
Q: Why do SOAP APIs need stricter XML validation than modern JSON APIs?
A: SOAP relies on parser-heavy XML processing, which creates unique abuse paths such as XXE, entity expansion and schema manipulation. Strict validation matters because the parser itself can become the attack surface when it is allowed to resolve external entities or accept malformed nested content.
Q: What do security teams get wrong about WS-Security in SOAP environments?
A: Teams often assume that signatures or encryption automatically protect the whole message, when in practice only parts of the payload may be validated. Misconfigured timestamp checks, replay tolerance and element substitution can leave an apparently secured SOAP service vulnerable to request abuse.
A: Teams should treat SOAP and XML services as part of the same API estate as modern REST, not as legacy exceptions. A practical approach is to centralise policy enforcement, validate message structure, transform payloads where needed, and route requests through a consistent governance layer. That reduces ad hoc handling and gives security, integration, and operations teams one place to control access and behavior.
Technical breakdown
Why exposed WSDL contracts expand attack reconnaissance
SOAP services publish formal WSDL contracts that describe operations, data types, endpoints and bindings. That makes integration predictable, but it also gives an attacker a service blueprint if the contract is exposed or poorly protected. Instead of guessing at hidden methods, an adversary can enumerate functions such as account lookup, policy updates or transaction calls and then craft payloads with precision. In security terms, the contract that improves interoperability can also compress reconnaissance time. The issue is not SOAP documentation itself, but the lack of access control, inventory discipline and endpoint hygiene around those contracts.
Practical implication: protect WSDL exposure as part of API inventory and access control, not as harmless documentation.
How XML parser and schema behaviour create SOAP-specific attack surface
SOAP depends on structured XML envelopes, strict schemas and parser-heavy processing. That combination creates failure modes that are less common in lightweight JSON APIs, including XXE, XML injection, entity expansion abuse and schema-based bypasses. When parser settings are permissive, an attacker can push the service to resolve external entities, consume excessive resources or mis-handle nested structures. Because SOAP often sits close to legacy infrastructure, these parser weaknesses can become entry points to data disclosure or service degradation. Safe operation depends on strict XML validation, disabled external entity resolution and careful schema enforcement.
Practical implication: validate parser hardening and schema controls on every SOAP endpoint that processes untrusted XML.
Why WS-Security fails when message-level controls are misconfigured
WS-Security adds signatures, encryption, timestamps and token handling to SOAP messages, but those controls are only effective when implemented correctly. A common failure pattern is verifying a signature while processing an attacker-controlled unsigned element, or allowing replay because timestamp freshness is not enforced. Message-level security also adds complexity to testing, which means teams may assume protection exists when only part of the chain is actually validated. For regulated workflows, that gap matters because integrity, non-repudiation and authorisation can all fail at the message layer rather than the transport layer.
Practical implication: test signed, encrypted and timestamped SOAP messages for verification gaps, replay tolerance and element substitution.
Threat narrative
Attacker objective: The attacker wants to reach high-value transactions or records through a SOAP interface that was assumed to be protected by legacy trust and incomplete message controls.
- Entry begins with exposure of the WSDL or an externally reachable SOAP endpoint that reveals supported operations and schemas.
- Credential or message abuse follows when the attacker exploits weak authentication, replayable tokens or misconfigured WS-Security to submit malicious requests.
- Impact occurs when XML parser abuse, access-control failure or workflow manipulation exposes sensitive records or triggers unauthorized business actions.
Breaches seen in the wild
- McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.
- T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SOAP security debt is really interface governance debt: the article shows that the core weakness is not the protocol but the way long-lived interfaces escape modern visibility, ownership and testing. SOAP remains embedded in critical workflows, yet many teams still treat it as inherited infrastructure rather than a governed control surface. Practitioners should manage SOAP as a live access and integrity domain, not as legacy plumbing.
Exposed WSDLs create a reconnaissance shortcut: when contracts reveal operations and schemas, attackers gain a precise map of the service before they ever send a malicious payload. That shifts SOAP defence from generic perimeter thinking to endpoint inventory, contract exposure control and request-level monitoring. Practitioners should assume contract exposure reduces attacker effort and respond accordingly.
Parser trust is the hidden failure mode in many SOAP estates: XML-based processing, schema validation and WS-Security can all fail in ways that are invisible until they are tested under abuse conditions. That is why SOAP security is closely tied to secure authentication and message validation, not only transport encryption. Practitioners should validate parser behaviour and signing logic as part of continuous assurance, not periodic exception handling.
High-value workflows deserve stronger assurance than modern teams often give them: banking, healthcare and government SOAP services often control transactions that have direct financial or regulatory impact. The category has survived because it is operationally important, but that importance is exactly why weak testing and ambiguous ownership are unacceptable. Practitioners should align SOAP oversight to the same governance standard used for privileged or regulated access paths.
Message integrity without lifecycle governance is not enough: SOAP’s strongest controls still depend on correct configuration, trusted identities and ongoing verification. That makes the protocol a useful reminder that access control failures are often governance failures first and technical failures second. Practitioners should treat SOAP as part of broader identity and API governance, especially where service accounts, tokens and delegated access touch critical systems.
From our research library:
- Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
- Read next: NHI Authentication Guide
What this signals
SOAP security debt is now a governance problem, not a protocol problem: organisations that still rely on SOAP need to manage it as a controlled interface estate, not as a legacy exception. That means contract exposure, parser hardening and message verification belong in the same assurance model as authentication and access review.
Contract visibility changes the threat model: when WSDLs are exposed, attackers do less guessing and more targeting, which is why SOAP inventory discipline matters. Teams that already govern APIs should extend those controls to SOAP before hidden endpoints become blind spots in privileged workflows.
Legacy interface risk now overlaps with identity governance: SOAP endpoints often depend on tokens, service accounts and delegated access that operate far beyond human review cycles. Access controls that are not tied to service ownership and runtime verification leave regulated workflows exposed even when the interface itself looks stable.
For practitioners
- Map every SOAP endpoint and WSDL Build and maintain an inventory of live SOAP services, exposed contracts and deprecated interfaces so owners know what is still reachable.
- Harden XML parsing and schema validation Disable external entity resolution, constrain recursive processing and enforce strict schema checks on all inbound SOAP messages.
- Test WS-Security message handling Validate signature coverage, timestamp freshness, replay handling and element substitution across authenticated SOAP operations.
- Add continuous SOAP testing to CI/CD Run schema-aware SOAP tests whenever WSDLs, service bindings or downstream dependencies change, and monitor for unexpected runtime behaviour.
Key takeaways
- SOAP remains embedded in critical workflows, but many organisations still underinvest in its inventory, testing and message-layer controls.
- The article highlights contract exposure, XML parser abuse and WS-Security misconfiguration as the main technical reasons SOAP stays risky.
- Continuous discovery, parser hardening and validated message protection are the controls most likely to reduce exposure in legacy SOAP estates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | SOAP misconfiguration, especially around WS-Security and parsing, is central to the article. |
| API2 — Broken Authentication | The article repeatedly points to weak or replayable SOAP authentication patterns. | |
| Recommendation — Harden SOAP configurations and verify that message handling, auth and schema controls are enforced consistently. Review SOAP authentication flows for replay tolerance, token handling and missing verification steps. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | SOAP risk here is often over-privileged access to high-value workflows and operations. |
| Recommendation — Align SOAP service permissions to least-privilege access and confirm only approved identities can invoke sensitive functions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SOAP message tokens and credentials need lifecycle control, rotation and revocation. |
| Recommendation — Manage SOAP authenticators so expired or replayable credentials are rotated and revoked on schedule. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | SOAP attacks can use exposed contracts and weak controls to reach authenticated operations and move deeper. |
| Recommendation — Map exposed SOAP attack paths to credential access and lateral movement to prioritise defensive testing. | ||
Key terms
- WSDL Contract: A WSDL contract is the machine-readable description of a SOAP service. It tells clients what operations exist, what data types are allowed, and where the endpoint lives. In security terms, it becomes both a governance artefact and a reconnaissance aid if attackers can retrieve it easily.
- Ws-Security: WS-Security is a set of standards for protecting SOAP messages through signatures, encryption, and identity assertions inside the message itself. It is powerful when enforced end to end, but partial or inconsistent implementation can create a false sense of safety because the control lives inside the payload, not just at the transport layer.
- XML Parser Abuse: XML parser abuse is the exploitation of weaknesses in how a service reads and interprets XML, including external entity resolution, recursive payload expansion and malformed structures. In SOAP environments, parser behaviour can turn a messaging layer into a direct attack surface.
- Signature Wrapping Attack: A signature wrapping attack tricks a system into validating one signed XML element while processing another, attacker-controlled element. In SAML, that usually means the verifier checks a legitimate signature but the application consumes forged identity claims from a different node.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management in a way that helps security teams connect access control to broader identity risk. It is suitable for practitioners who need to align identity governance with the systems and interfaces their programmes still depend on.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org