SOAP API security gaps persist in legacy systems and critical workflows

At a glance

What this is: This is an independent analysis of why SOAP APIs remain a high-risk legacy surface, especially where XML complexity, exposed contracts, and weak visibility combine.

Why it matters: It matters because SOAP often protects core transactions and regulated workflows, so identity, access control, and message integrity failures can translate directly into business impact.

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.

👉 Read LEVO's analysis of SOAP API security risks and testing priorities

Context

SOAP is not a legacy curiosity when it still carries transactions, claims, records exchange, and other high-value operations. The problem is that many organisations modernised around it, not through it, leaving older endpoints less visible, less tested, and more exposed to attackers who understand that critical systems are often the least observed.

For identity and access teams, the key issue is governance of message-level trust, not just perimeter protection. SOAP contracts, WS-Security headers, and XML parsing rules can all create assurance when they are configured correctly, but they can also create hidden failure modes when teams assume those controls are working because the service is still functioning.

The typical enterprise pattern is still to prioritise REST and treat SOAP as an inherited exception. That starting position is common, but it is no longer defensible where SOAP remains tied to regulated workflows and privileged backend actions.

Key questions

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. The risk is highest when old SOAP services remain online after migrations and still connect to privileged backend systems. Governance must treat exposure of the contract as part of the attack surface, not just a documentation detail.

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. If authentication, authorisation, or message integrity is weak, attackers can move from discovery to direct manipulation of high-value operations. The risk is not volume alone, but the sensitivity of the actions behind the endpoint.

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. A service can appear secure and still accept attacker-controlled XML if the parser allows external entities or the backend processes the wrong signed element. Effective testing has to include both protocol compliance and parser abuse scenarios.

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.

Technical breakdown

How SOAP contracts expose attack surface through WSDL and XML schemas

SOAP is contract-first. A WSDL defines operations, data types, bindings, and endpoints, while XML schemas specify what the service will accept and return. That design improves predictability, but it also gives attackers a blueprint if the contract is exposed. They can enumerate functions, identify privileged operations, and craft payloads that target known request shapes. Because SOAP is strongly typed, many failures arise not from the protocol itself but from overly permissive schema handling, weak endpoint exposure controls, or assumptions that internal consumers are inherently trusted.

Practical implication: restrict WSDL exposure, review schema permissions, and treat contract publication as an access-control decision rather than a convenience.

WS-Security misconfiguration and message-level trust failures

WS-Security adds signatures, encryption, timestamps, and token-based authentication at the message layer. In principle, that supports non-repudiation and integrity across intermediaries. In practice, teams often validate a signature but process the wrong element, reuse stale timestamps, or fail to bind the signature to the exact payload that is executed. That is how signature wrapping and replay flaws appear. The control is not simply having WS-Security enabled. The control is verifying that the signed, encrypted, and authorised message is the one the backend actually consumes.

Practical implication: test signature binding, replay resistance, and timestamp enforcement against live SOAP operations, not just configuration checklists.

XML parser behaviour, XXE, and schema-driven denial of service

SOAP depends on XML parsing, which expands the attack surface well beyond the business logic. If the parser allows external entities, attacker-controlled documents can try to reach local files or internal resources. If nested entities or recursive structures are not constrained, the service can be forced into resource exhaustion. Schema validation is helpful, but only when it is paired with secure parser settings, entity blocking, depth limits, and load testing. In other words, SOAP security is partly an application problem and partly a parser governance problem.

Practical implication: lock down parser features, disable external entities, and test for XXE and XML DoS before production cutover.

Threat narrative

Attacker objective: The attacker wants direct access to sensitive transactional functions and the business data or operational control those SOAP services expose.

1. Entry occurs through exposed WSDLs, deprecated endpoints, or other SOAP surfaces that reveal operations and message structure to an attacker.
2. Escalation follows when weak XML parsing or misconfigured WS-Security allows replay, signature wrapping, or parser abuse against privileged functions.
3. Impact is realised when attackers reach high-value business operations such as payment actions, policy updates, or record access through the compromised service path.

NHI Mgmt Group analysis

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.

Exposed contracts create an information advantage for attackers. A published WSDL is not automatically a vulnerability, but it becomes one when discovery is wider than intended and downstream controls are weak. The combination of predictable schemas and privileged operations gives adversaries a map of what to probe first. In NIST-CSF terms, this is an identification and protection problem, and in identity terms it is a boundary problem around who can invoke what, when, and with which message-level assurances.

SOAP increases the cost of configuration mistakes, not just their likelihood. XML parsing, signatures, encryption, timestamps, and routing headers all need to line up correctly. If they do not, the result is often not a graceful failure but a silent trust break. That is why SOAP governance should be assessed as a runtime assurance problem, not only as a development standard. Practitioners should assume configuration drift until testing proves otherwise.

Legacy API estates need a named concept: SOAP governance debt. This is the accumulation of undocumented endpoints, outdated assumptions, and under-tested message handling in services that remain business critical. It is not the same as generic technical debt because the exposure is concentrated in privileged, regulated, and long-lived integrations. Teams should treat SOAP governance debt as an inventory, testing, and offboarding priority before it becomes an incident driver.

What this signals

SOAP governance debt: organisations that keep legacy SOAP services alive without continuous discovery and regression testing are carrying a hidden trust-boundary liability. The next phase of exposure is less about the protocol itself and more about stale assumptions around who can invoke it, how XML is parsed, and whether message-level security is still binding the right elements. Where SOAP interfaces touch identities or privileged business functions, align the controls with NIST Cybersecurity Framework 2.0 and map message-level trust assumptions to access governance.

Teams should expect SOAP risk to surface during migrations, not only during active development. The danger pattern is endpoint persistence after modernisation, especially when WSDLs, parser settings, and runtime monitoring are left behind by the broader application programme. Continuous discovery and testing reduce surprise, but only if legacy services are folded into the same control review cadence as newer APIs.

For identity-heavy integrations, SOAP is another reminder that access control is not only about who logs in. It is also about who can submit a valid message, whether the signed payload is the one executed, and whether the workflow behind the interface is still appropriate for production use. That is where API governance, identity governance, and runtime assurance now overlap.

For practitioners

• 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. Remove any assumption that internal routing makes them low risk.
• 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.
• Move SOAP testing into CI/CD and runtime monitoring Run schema-aware tests whenever a WSDL changes or a service is redeployed, and watch runtime traffic for unusual XML structures, unexpected callers, or repeated faults.

Key takeaways

• SOAP APIs remain operationally critical, but their security posture is often weaker than the value of the systems they protect.
• The most dangerous failures are contract exposure, WS-Security misconfiguration, and XML parser abuse, not the protocol label itself.
• Continuous discovery, parser hardening, and message-level trust testing are the controls that reduce SOAP risk in mixed API estates.

Key terms

• API Secret: An API secret is a credential that allows a machine or application to access an API. It may be a key, token, password, or certificate. If exposed, reused, or left long-lived, it can be copied by attackers and used to impersonate the original workload.
• 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 SOAP extension that adds message-level protections such as signatures, encryption, timestamps, and token-based authentication. It can provide strong assurance, but only if the service verifies the exact signed content, rejects replay attempts, and binds security controls to the payload actually processed.
• 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.

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

👉 LEVO's full article covers schema-aware testing, runtime monitoring, and legacy SOAP security controls in more depth

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building stronger access control. It helps security teams connect identity lifecycle discipline to the wider controls their programmes depend on.