SOAP API Security Testing: Complete 2026 Guide to Securing SOAP, WS-Security & XML-Based APIs

Although often viewed as legacy, SOAP remains critical in 2026, supporting financial transactions, claims processing, and medical record exchanges. While REST leads new development, SOAP still processes trillions of dollars daily and is integral to banking, healthcare, telecom, and government operations. Its longevity underscores both its importance and its growing risk.

API attacks have increased significantly in recent years. Malicious API traffic has risen by 681%, and 95% of organizations experienced at least one API security incident in the past year. APIs now account for about 70% of web traffic, making them a primary target. SOAP is often the weakest link because it supports legacy systems, receives less attention, and depends on skills that many teams lack.

Securing SOAP is also more challenging. Its XML envelopes, strict schemas, and WS Security layers increase the risk of misconfiguration. Many teams prioritize REST security, leaving SOAP endpoints under tested and under protected, despite their role in safeguarding high value assets.

Levo.ai helps teams bring this level of assurance to their SOAP APIs with real time API visibility, automated security testing, and privacy first observability built directly into CI CD pipelines.

What Is a SOAP API? Definition, Architecture & How SOAP Works (XML, WSDL, WS-Security)

In simple terms, a SOAP API is a strongly typed XML based service that guarantees predictable and interoperable communication between systems.

A SOAP API is a web service interface built on the SOAP protocol. SOAP uses structured XML messages wrapped in a strict envelope format that includes an Envelope element, optional Header metadata, a Body containing the request or response, and an optional Fault element for errors. 

Every SOAP service is defined by a WSDL contract that specifies all operations, inputs, outputs, data types and endpoints. This contract acts as a formal agreement that clients must follow. SOAP can operate over HTTP, HTTPS, SMTP or other transports, although HTTPS is the most common in 2025.

Why SOAP APIs Still Matter in 2026: Security, Reliability & Compliance Benefits

SOAP continues to run many core enterprise systems, especially where security, reliability and compliance cannot fail. Its WS Security features, including XML encryption, digital signatures and SAML based authentication, provide strong message integrity and non-repudiation that regulated industries still rely on. SOAP also supports reliable messaging and transactional guarantees that protect financial and clinical workflows from data loss.

The WSDL contract model gives CISOs predictable governance. Every input, output and operation is formally defined, reducing integration drift and limiting the chance of hidden or undocumented functionality appearing in production.

Industry standards reinforce this dependence. Networks such as SWIFT and healthcare frameworks like HL7 and DICOM still require SOAP for secure and auditable data exchange. For many organisations, these systems are too critical to replace, so SOAP remains the trusted foundation where assurance and control matter most.

SOAP Architecture Explained: XML Messaging, WSDL Contracts & WS-Security Layers

SOAP uses a contract first architecture that revolves around structured XML messaging and tightly defined service interfaces. Everything in SOAP is driven by formal rules: how messages are shaped, how operations are exposed and how clients and servers must interact. This predictability is why SOAP continues to support high assurance systems.

SOAP Message Structure: Envelope, Header, Body & Fault Explained

At the core of SOAP is its XML based message format. Every interaction is wrapped in a single envelope, ensuring a uniform structure across all implementations.

• The Envelope is the root wrapper that contains the entire message.
• The Header carries optional metadata such as authentication tokens, routing information, timestamps or WS Security elements.
• The Body contains the actual operation payload, structured precisely as defined in the service schema.
• The Fault element provides a consistent error structure when processing fails.

This message format is deliberately strict, creating a shared language between clients and servers regardless of platform or programming language.

WSDL in SOAP: How Service Contracts, Schemas & Operations Define Behavior

The message structure is only half of the story. SOAP also requires a formal service contract, published as a WSDL. The WSDL defines:

• every operation the service exposes
• the exact input and output schemas
• allowed data types and constraints
• the endpoint address and binding details

Clients and tools generate request stubs directly from the WSDL, and servers validate incoming XML against it. This contract driven approach guarantees that all parties adhere to the same rules. It also explains why SOAP integrations fail fast when XML does not conform to the schema.

SOAP Runtime Execution Flow: How Requests Are Validated & Processed

Because SOAP enforces rules at both the message and contract level, the runtime flow is predictable.

A client sends an XML request that matches the WSDL defined schema, typically over HTTPS using HTTP POST. The SOAP engine validates the structure, unmarshals the XML and maps it to the corresponding operation.

Backend logic is executed, potentially involving additional downstream services or legacy systems. The engine returns a structured SOAP response or a Fault message.

This strict flow reduces ambiguity but places responsibility on teams to configure XML parsing and schema validation correctly.

WS-Security & WS Extensions: Signatures, Encryption, Policy & Routing

SOAP becomes more potent through the WS star extensions, which plug into the Header and expand its capabilities.

• WS Security adds XML signatures, encryption, timestamps and token based authentication.
• WS Addressing supports routing metadata and message correlation.
• WS Policy communicates required capabilities such as specific token types or encryption requirements.

These extensions are integral in large US enterprise environments, especially in finance and healthcare, where message integrity and non repudiation are mandatory.

Older SOAP Components

Earlier SOAP deployments sometimes used UDDI registries to publish and discover WSDLs. While less common today, they illustrate SOAP’s emphasis on formal discovery and governance.

In many US enterprises, these older SOAP integrations still sit close to financial, clinical or operational systems, which is why getting the architecture and controls right continues to matter.

Why SOAP APIs Are Prime Attack Targets: High-Value Systems & Legacy Weaknesses

SOAP APIs often guard the systems attackers care about most. They handle money movement, medical records, billing events and identity data. When these services are compromised, the impact is immediate and measurable. Several factors make SOAP a preferred target.

1. SOAP APIs often sit within crown jewel systems

Many SOAP services power core banking, claims processing, trading, telecom provisioning and government workflows. These APIs are tightly coupled to mainframes and transaction engines, so a successful exploit can directly access high value data or trigger high impact operations.

2. Legacy status often means lower security visibility

Rest APIs typically receive the bulk of modern security investment. Older SOAP integrations may not have modern observability, rate limiting or runtime monitoring in place. They may also run on older infrastructure or on internal networks that teams assume are safe. Attackers actively scan for these “out of sight” endpoints because they are often under tested and under patched.

3. WSDLs give attackers a complete blueprint

If an attacker can retrieve the WSDL, they instantly learn every operation, input and output structure the service supports. This removes the guesswork from reconnaissance. They can see which methods perform account lookups, policy updates or fund transfers and craft payloads accordingly.

4. Many SOAP services are left online after migrations

A typical pattern is to modernise an application to REST while leaving the original SOAP service running for “temporary” compatibility. In several breaches, attackers found a deprecated SOAP endpoint still connected to production systems. One healthcare incident exposed hundreds of thousands of patient records because an unused SOAP service was never decommissioned.

5. Complex XML parsing creates more attack surface

SOAP’s reliance on XML makes it vulnerable to threats like XXE, XML bombs and schema based injections. If XML parsing is misconfigured, an attacker can exploit the parser itself or use oversized payloads to degrade the service.

6. High impact operations are often exposed directly

It is common for SOAP interfaces to include administrative or privileged operations (resetting balances, updating policy attributes, changing service flags). If access control is weak or tokens can be replayed, attackers gain direct access to sensitive functionality.

‍

SOAP APIs combine three risk multipliers. They control high value operations, receive less ongoing attention and provide attackers with evident technical insight through the WSDL. For adversaries, this makes SOAP a high reward and often lower resistance target compared to modern APIs.

SOAP API Security Fundamentals: Confidentiality, Integrity, Authentication & XML Protection

Securing SOAP APIs starts with the same core goals as any high value integration: protect confidentiality, preserve integrity, ensure availability and enforce strict identity controls. What makes SOAP different is that these protections must be applied to XML based messages, a formal contract and a message processing pipeline that is more complex than most REST implementations. The fundamentals below work together, not in isolation.

1. Confidentiality

Confidentiality begins at the transport layer, where TLS protects SOAP messages from interception. However, SOAP often requires protection beyond the network. Many SOAP deployments rely on WS Security encryption to secure sensitive XML elements inside the message itself. This allows organisations to protect high value data flowing through intermediaries and layered infrastructure. As a result, confidentiality in SOAP environments is typically achieved through encrypted channels and encrypted XML content.

2. Integrity and Authenticity

Where confidentiality protects the contents, integrity ensures they have not been tampered with. SOAP achieves this through WS Security digital signatures, which bind specific XML elements to a trusted identity. These signatures verify that a message is unchanged, that it comes from a valid source and that critical operations cannot be modified in transit. In industries that rely on SOAP for financial or clinical workflows, these guarantees are as crucial as encryption.

3. Authentication and Authorization

Once a message arrives intact, the service must verify who sent it and what they are allowed to do. SOAP frequently uses header based tokens, such as UsernameToken, SAML assertions or OAuth style tokens. Whatever the mechanism, each request must map cleanly to an identity and be checked against explicit access control rules. SOAP operations are often high impact, so least privilege is essential. Every operation should have clear role requirements, and unauthorised calls must be rejected before business logic executes.

4. Input Validation and XML Handling

Even with strong identity controls, SOAP remains vulnerable if XML parsing is not secured. Unlike JSON, XML can carry dangerous constructs such as external entities or deeply nested structures. Validating incoming messages against the WSDL or XSD schema is the first line of defense. Services must also sanitise user controlled fields to prevent SQL, command or XPath injection and disable unsafe XML features like external entity expansion. Because SOAP engines process complex XML, misconfigured parsers are among the most common root causes of SOAP vulnerabilities.

5. Defense in Depth

Adequate SOAP security requires combining several layers:

• strong authentication for every request
• strict authorization for every operation
• schema based XML validation
• limits on message size and complexity
• encryption and signatures through WS Security
• secure XML parser configuration
• network level controls such as TLS and firewall restrictions

Common SOAP API Vulnerabilities: XXE, XML Injection, Replay, WS-Security Flaws & More

SOAP APIs face many of the same risks as modern web services, but those risks often appear in XML specific forms. Because SOAP relies on typed XML, schema validation and WS Security, any weakness in these components can create high impact exposure. 

Every major SOAP vulnerability ties back to one of four root causes:

• Complex XML parsing
• Over reliance on headers and tokens
• Automatic trust in WSDL exposed operations
• Misconfigured WS Security layers

Understanding these patterns is essential because attackers know SOAP’s weak spots and target them precisely.

Below are the most significant vulnerabilities, each tied to how attackers exploit them in real systems : 

1. SQL/XML Injection in SOAP APIs: How Attackers Abuse XML Payloads

SOAP messages carry user supplied data inside XML fields. If these fields are not sanitised, attackers can inject malicious content.

An attacker places a payload such as ' OR '1'='1 inside an XML element like <UserID> or <AccountName>. If the backend uses that field in a database query without validation, SQL injection becomes possible. Similarly, if XML data is passed to system commands or file operations, command injection can occur. The XML structure does not prevent injection. Only validation and sanitisation do.

Real Life Use Case

A financial SOAP service exposed a <CustomerID> field that was directly concatenated into a SQL query. A crafted SOAP request allowed attackers to bypass authentication and enumerate customer records. Another frequent pattern involves injecting a malicious <!DOCTYPE> element to trigger XXE behaviour.

2. SOAP Action Spoofing Attacks: How Operation Mismatch Leads to Exploits

SOAP over HTTP uses a SOAPAction header to indicate which operation is being invoked. If servers trust this header without verifying the body, attackers can manipulate which method is executed.

An attacker on an unencrypted connection modifies the SOAPAction header to call a privileged operation, while keeping the body largely unchanged. If the server routes based only on the header, it may invoke an unintended method.

The protocol separates the operation name (header) from the operation content (body). If they are not cross checked, mismatch attacks occur.

Real Life Use Case
A telecom provisioning API trusted the SOAPAction header, allowing attackers to trigger administrative operations that were never exposed to regular clients.

3. SAML Token & XML Signature Wrapping Vulnerabilities Explained

SOAP APIs often use SAML assertions or signed headers for authentication. Improper signature validation can allow attackers to insert malicious elements that the signature does not cover.

Attackers wrap a fake <Assertion> element inside the message and move the signed one elsewhere. If the server verifies the signature but processes the attacker controlled assertion, privilege escalation occurs.

WS Security signatures operate on individual XML nodes. Manipulating their position or duplicating them can bypass naive verification.

Real Life Use Case
Multiple enterprises have been breached through XML Signature Wrapping, in which attackers impersonated admin users despite valid signatures being present.

4. SOAP Replay Attacks: How Attackers Reuse Signed or Encrypted Requests

SOAP often handles critical transactions. Without nonces or timestamps, attackers can capture and replay valid messages.

A genuine request, such as a <TransferFunds> operation, is intercepted and resent multiple times. Without replay protections, the system treats each request as valid.

Header based authentication and long lived tokens make replay feasible unless the API enforces freshness.

Real Life Use Case
Payment APIs have experienced repeated fund transfers due to replayed SOAP messages lacking unique timestamps or nonce validation.

5. XML Specific Attacks (XXE, XML Bombs, Parser Abuse)

Because SOAP is XML based, it inherits all XML parsing risks.

XXE attacks exploit external entity references to read local files or trigger SSRF. “Billion Laughs” payloads overload the XML parser to cause denial of service. Deeply nested elements or massive arrays cause resource exhaustion. 

SOAP engines process XML automatically. Unsafe parser settings can expose internal files, memory, and CPU resources.

Real Life Use Case
A legacy insurance SOAP service was taken offline for hours by a single oversized SOAP request containing deeply nested XML, overwhelming the parser.

6. Cross Site Scripting (XSS) in SOAP Responses

While SOAP is primarily server to server, XSS can appear in dashboards or interfaces that display SOAP faults or responses.

User controlled XML fields are echoed inside a SOAP Fault or response. If an admin portal renders that XML in a browser without sanitisation, JavaScript executes.

SOAP does not prevent script injection. Any response consumed in a browser is vulnerable.

Real Life Use Case
A hospital admin dashboard ingested SOAP Faults directly. Attackers injected a <script> tag into a customer name field, resulting in stored XSS when the dashboard displayed the error.

7. Broken Access Control in SOAP: IDOR, BOLA & Privilege Escalation

SOAP services often expose numerous operations, including administrative ones. If access control is not enforced server side, attackers can invoke functions they should not have access to.

Attackers change IDs in XML fields, invoke admin only operations or bypass client side restrictions.

WSDL documents list all operations. Attackers know exactly which functions to target.

Real Life Use Case
A government system exposed an operation <GetCitizenRecordByID>. Attackers replaced their own ID with another user’s ID inside the SOAP Body and retrieved records because the API did not verify ownership.

8. Denial of Service (DoS) via XML Complexity or Message Flooding

SOAP processing is CPU and memory intensive. Attackers use oversized payloads, nested XML or high frequency requests to degrade or crash the service.

DoS via XML Complexity happens by sending massive SOAP envelopes, abusing schema based processing, or sending large numbers of requests to heavy operations.

SOAP is affected because XML schema validation and WS Security signature verification are expensive operations.

Real Life Use Case
A telecom SOAP service that performed provisioning was taken offline due to repeated large XML messages that triggered heavy schema validation and exhausted CPU.

SOAP API Security Testing Methodology: Step-by-Step Guide for Manual & Automated Testing

Testing SOAP APIs requires a structured approach that covers the entire request lifecycle: discovery, contract analysis, authentication, input handling, message behaviour and backend impact. Because SOAP relies on strict XML schemas and WS Security, effective testing must verify both the protocol mechanics and the business logic underneath.

1. Identify SOAP Endpoints and Gather Artefacts

The first step is confirming what actually exists.

• Locate SOAP endpoints through documentation, proxies, gateways or traffic captures
• Retrieve WSDLs and any associated XSDs
• Identify all exposed operations, request parameters and data types

WSDLs give testers a complete view of the attack surface. For example, discovering an unused <UpdateUserRole> operation in the WSDL often exposes privilege escalation paths that are not visible from the frontend.

2. Understand the Service Contract

SOAP is contract driven, so testing begins with the WSDL.

• Map each operation to expected inputs and outputs
• Identify optional vs required fields
• Note schema restrictions such as length, formats or enumerations
• Determine security requirements defined by WS Policy

A careful contract review often reveals logic gaps. For example, an operation may accept a <UserID> field with no constraints, signalling a potential for ID tampering or object level access issues.

3. Assess Authentication and Session Handling

Test how the SOAP service verifies identity.

• Replay existing tokens such as UsernameToken or SAML
• Try expired, forged or unsigned tokens
• Check whether the server validates timestamps or nonces
• Confirm whether tokens are bound to operations or can be reused across methods

For example, replaying a captured SAML assertion may succeed if the server does not enforce clock skew or unique message IDs, resulting in replay attacks.

4. Validate Authorization on Every Operation

SOAP APIs often expose admin or high impact functions.

• Attempt invoking operations with insufficient privileges
• Modify role related attributes inside the XML body
• Test whether the service enforces ownership checks on identifiers
• Validate that server side access control is applied, not just client side logic

A common failure occurs when <GetRecordByID> returns arbitrary data simply because the caller provided a different ID.

5. Test Input Validation and Schema Enforcement

The XML payload must match the schema, but many services do not enforce validation.

• Send malformed XML structures
• Break the schema intentionally by altering data types
• Inject payloads that exceed defined length or format constraints
• Attempt to bypass validation by nesting unexpected elements

If the service processes malformed XML without rejecting it, downstream code paths become vulnerable to injection and parsing exploits.

6. Perform XML Focused Attack Testing

Because SOAP relies on XML, parser behaviour is a core security concern.

• Attempt XXE payloads using external entities
• Test for Billion Laughs, quadratic blowup or nested XML DoS attacks
• Evaluate how the service handles DTDs, external references and deep recursion
• Validate whether secure parser settings are enabled

An example failure is a parser that processes external entities, allowing attackers to read server files via file:/// URIs.

7. Evaluate WS Security Controls

WS Security is robust but often misconfigured.

• Check signature validation by modifying signed elements
• Test signature wrapping attacks by inserting duplicate nodes
• Confirm encryption is applied to the intended XML fields
• Validate timestamp freshness and replay protections

Many real incidents stem from a server verifying a signature but processing an attacker controlled unsigned element.

8. Test Business Logic and Workflow Weaknesses

SOAP often powers critical workflows such as billing, provisioning or payments.

• Evaluate multi step processes for bypasses
• Insert invalid state transitions
• Manipulate IDs or amounts inside transaction operations
• Observe how the system recovers from partial or failed steps

For example, sending a second request during a multi step provisioning sequence may allow an attacker to create inconsistent or unintended states.

9. Assess Error Handling and Fault Responses

SOAP Faults often leak internal implementation details.

• Trigger faults by sending unexpected values
• Check whether stack traces, query strings or internal service names are exposed
• Ensure the API does not echo untrusted input inside Fault messages (XSS risk)

This is especially important when admin dashboards consume SOAP responses.

10. Run Availability and Performance Safety Checks

SOAP engines validate XML, verify signatures and sometimes run transformations, all of which increase processing cost.

• Test rate limits
• Send oversized requests
• Validate schema heavy operations under load

Resource exhaustion is a standard failure mode when XML validation is expensive or recursive structures are not capped.

Manual vs Automated SOAP Security Testing: Pros, Cons & Best Use Cases

SOAP security testing benefits from both human expertise and automation. Manual testing uncovers subtle logic flaws, while automated testing provides scale, regression coverage and continuous assurance. 

The table below highlights how each approach contributes to a complete security program :

Best SOAP API Security Testing Tools (2026): Levo.ai, SoapUI, Burp, ZAP, AppScan & More

Enterprises continue to run mission critical systems on SOAP services, securing them is non-negotiable. Here are the top SOAP API security testing tools that help teams validate configurations, enforce standards, and detect vulnerabilities before they reach production:

1. Levo.ai

Levo.ai provides continuous, automated API security testing for SOAP services by analysing WSDL contracts, discovering hidden or deprecated operations and generating deep semantic tests across authentication, WS Security and XML parsing layers. It validates both message level protections and backend logic, catching issues such as XML Signature Wrapping, privilege escalation, and schema bypasses that legacy scanners routinely miss.

What sets Levo apart is its runtime informed testing. Instead of relying on manually supplied WSDLs or static payload libraries, Levo observes real API traffic to automatically discover every SOAP endpoint and operation, including long forgotten internal methods. It then generates schema aware, contextually valid attack payloads that mirror real usage patterns, ensuring well formed XML, accurate types and tests that exercise actual business logic rather than artificial fuzzing.

Levo also natively handles complex WS Security flows (UsernameToken, SAML, signed and encrypted messages, mTLS) without manual scripting, enabling full authenticated coverage. Its anomaly detection monitors live SOAP traffic for suspicious XML structures or access patterns, and its access control engine automatically tests for BOLA/IDOR and role abuse using runtime derived parameters.

With real time visibility, privacy first observability and CI/CD ready automation, Levo.ai delivers enterprise grade SOAP coverage at a scale traditional tools cannot match, unifying depth, frequency and full API coverage in a single platform designed for both legacy SOAP ecosystems and modern API environments.

2. SoapUI / ReadyAPI (SmartBear)

SoapUI and its commercial counterpart ReadyAPI remain the most widely used tools for manual and semi automated SOAP testing. They can import WSDLs, generate request stubs, apply WS Security policies, and run fuzzing tests across operations. ReadyAPI adds security test packs that target SQL injection, XXE, and XPath injection in SOAP messages. These tools excel for handson analysis and functional plus security testing but rely heavily on manual configuration and do not provide continuous security coverage.

3. Burp Suite (with SOAP Extensions)

Burp Suite can intercept, modify and replay SOAP requests, making it a strong option for manual or hybrid testing. With community extensions for SOAP message parsing and WSDL importing, Burp enables researchers to manipulate WS Security headers, test SOAPAction spoofing, replay SAML tokens and inject malicious XML structures. Burp is particularly effective for identifying business logic flaws in high value SOAP operations.

4. OWASP ZAP (SOAP Support Add On)

ZAP’s SOAP Add On allows testers to import WSDLs, crawl SOAP services and generate attack payloads automatically. It supports scanning for injection vulnerabilities, insecure XML parsing, and simple authentication weaknesses. While not as comprehensive as commercial scanners, ZAP is a strong, open source option for teams that want basic SOAP security automation alongside manual exploration.

5. Invicti (Acunetix)

Invicti offers a WSDL aware DAST engine that automatically imports and scans SOAP endpoints discovered during a web scan. It tests for XML injection, SQL injection, XXE, authentication bypasses, and insecure SOAPAction handling. Invicti is well suited for broad automated coverage but can struggle with highly customised WS Security flows or multi step transactional logic often seen in enterprise SOAP systems.

6. Qualys WAS

Qualys Web Application Scanning supports basic SOAP scanning when a WSDL is provided. It generates request templates and probes for common SOAP weaknesses such as injection flaws and misconfigured authentication. Qualys is frequently used in compliance driven programs where periodic scanning is required, though its SOAP capabilities are less advanced than dedicated API testing tools.

7. Bright Security (NeuraLegion)

Bright Security provides a developer focused DAST platform capable of scanning SOAP services by fuzzing XML fields, testing schema boundaries and validating WS Security handling. Bright is known for low false positives and CI friendly pipelines. Its strength lies in broad automation, though it may require tuning for complex SOAP workflows such as multi message operations or advanced signature validation.

8. AppScan (IBM Security)

IBM AppScan supports SOAP security testing via WSDL imports, enabling automated generation of SOAP requests and payload variations. It targets issues such as XML entity abuse, authentication weaknesses and schema violations. AppScan is often adopted in large enterprises with mature AppSec programs, particularly in regulated industries with extensive legacy SOAP integrations.

9. APIsec

APIsec can test SOAP services using WSDL definitions or traffic captures. It automates fuzzing and injection testing across SOAP operations and provides workflow based test modelling for business logic issues. While its core strength is modern REST APIs, APIsec can support SOAP testing in organisations with mixed architectures.

10. Parasoft SOAtest

Parasoft SOAtest is one of the most mature tools for testing SOAP services, particularly in large enterprises that rely heavily on WSDL driven integrations. It provides deep support for WS Security, schema validation, message level encryption, and signature testing, along with automated generation of SOAP requests from WSDLs. SOAtest can validate end to end SOAP workflows, emulate backend services and apply complex policy validations across multi step transactions. Its strength lies in comprehensive functional plus security testing for legacy SOAP systems that require compliance grade assurance.

SOAP Security Best Practices: WS-Security, XML Validation, Access Control & CI/CD Testing

Securing SOAP services requires a layered strategy. SOAP provides robust security features such as WS Security, but they only work when paired with disciplined validation, strong identity controls, hardened XML parsing and continuous operational oversight. 

The following best practices strengthen SOAP APIs against modern threats while keeping the guidance practical for engineering and security leaders: 

1. Validate Inputs Rigorously

SOAP services must treat every incoming message as untrusted. Enforce strict schema validation using the service’s WSDL and XSD so only expected structures and data types are accepted.

Core actions

• Validate all XML against the schema before processing
• Reject any value that violates type, length or format rules
• Allow only expected characters or patterns (whitelisting)
• Enforce business rules (e.g., IDs must be positive, dates must be valid)
• Validate HTTP metadata: only accept intended methods such as POST and correct Content Type

Example:

If <AccountID> is defined as a positive integer, a value like  1 or ' OR 1=1 should fail at the schema layer long before it reaches business logic. This stops most injection and malformed XML exploits early.

2. Implement Strong Authentication and Session Management

SOAP supports multiple authentication models. Use well established standards instead of custom schemes and ensure credentials are always protected.

Core actions

• Require authentication for all sensitive operations
• Use TLS for transport and WS Security UsernameToken, SAML or OAuth for message authentication
• Avoid sending plain credentials in the message
• Enforce session timeouts and secure session IDs for stateful services
• Add anti replay protections: WS Security nonces and timestamps

Example

A captured SAML token should not be reusable. A timestamp or nonce check should force the server to reject any replayed <TransferFunds> request even if the signature is valid.

3. Enforce Authorization and Least Privilege

Authentication answers “who are you”; authorization answers “what are you allowed to do.” SOAP operations are often high impact, so authorization must be strict.

Core actions

• Apply role and permission checks on the server side for every operation
• Deny access by default and grant only required privileges
• Restrict sensitive operations (such as, fund transfers or record changes) to specific roles
• Use network controls such as allowlists or mTLS for internal only services
• Log all authorization failures for audit and detection

Example

If a <GetPatientRecord> operation is meant only for clinicians, a patient should not retrieve another patient’s record simply by modifying the <PatientID> field in the SOAP Body.

4. Apply Message Level Security with WS Security

Transport encryption (TLS) is essential, but SOAP often requires protecting the message itself, especially when messages pass through multiple intermediaries.

Core actions

• Sign critical XML elements such as the SOAP Body or Timestamp
• Encrypt sensitive fields such as account numbers or identifiers
• Use X.509 certificates for stronger identity than passwords
• Publish WS SecurityPolicy in the WSDL so clients know what is required
• Rotate and secure private keys properly

Example

Signing the entire Body ensures that a malicious intermediary cannot modify fields like <Amount> in a financial transaction without breaking the signature.

5. Protect Against XML Specific Attacks

SOAP inherits all XML parser risks, so restricting parser behavior is essential.

Core actions

• Disable external entity processing (XXE)
• Block DTDs unless absolutely required
• Set maximum XML depth, element counts and message sizes
• Enable protections against “billion laughs” or other expansion attacks
• Harden deserialization if converting XML to objects

Example

An attacker submitting a crafted <!DOCTYPE> with external entities should not be able to read file:///etc/passwd or trigger SSRF via malicious URLs. Proper parser settings make this impossible.

6. Use HTTPS Everywhere and Harden Network Configuration

SOAP should always be delivered over encrypted and tightly controlled channels.

Core actions

• Enforce HTTPS only
• Use strong, modern cipher suites
• Place SOAP services behind firewalls or API gateways
• Restrict inbound IP ranges where possible
• Disable unnecessary ports, services and verbose error messages

Example

A SOAP endpoint that still accepts plain HTTP traffic provides attackers an easy opportunity to capture credentials or tokens. Enforcing HTTPS at the edge removes this risk entirely.

7. Integrate with Central Identity and Access Management

A central IAM system strengthens oversight and reduces the burden on individual services.

Core actions

• Use SAML or OAuth tokens issued by an identity provider
• Apply MFA where end user authentication is involved
• Delegate token validation to a gateway or IAM component
• Maintain centralized policies for password rotation, token expiry and audit

Example

Fronting a SOAP API with an IAM gateway allows the service to trust a validated identity header rather than implement SAML parsing logic itself, reducing code complexity and risk.

8. Logging, Monitoring and Alerts

Visibility is critical because SOAP attacks often go unnoticed without proper telemetry.

Core actions

• Log authentication attempts, failures and denied operations
• Monitor for abnormal input sizes or repeated schema failures
• Track SOAP Fault spikes as indicators of probing
• Forward logs to a SIEM for alerting and correlation

Example

A spike of oversized SOAP requests may indicate an XML DoS attempt; a monitoring rule should flag this within seconds.

9. Secure the Deployment Pipeline

SOAP security must extend through development, testing and deployment.

Core actions

• Run static code analysis for injection and unsafe parsing patterns
• Check SOAP framework dependencies for CVEs
• Integrate automated SOAP security testing into CI CD
• Perform security reviews for new WSDLs or changed operations
• Maintain an inventory of all SOAP services

Example

A new <UpdateUserRole> operation appearing in a WSDL should automatically trigger a security review to ensure it enforces proper authorization.

10. Avoid Leaking Secrets in URLs or Logs

SOAP data often flows through multiple systems, so accidental exposure must be avoided.

Core actions

• Never place API keys or tokens in URLs
• Mask sensitive fields in logs
• Disable verbose SOAP Faults that echo user input
• Review log storage for sensitive payloads

Example

A token included in a query parameter can end up in load balancer logs, browser history or network proxies, making it far easier for attackers to steal.

SOAP vs REST Security: Why SOAP APIs Are Harder to Secure & Maintain

SOAP APIs can be secured to a high standard, but doing so is significantly more complex than securing REST APIs. The difficulty stems from SOAP’s architecture, its security model, and the environments where SOAP typically runs.

Several factors make SOAP more challenging to protect in practice : 

1. A Larger and More Complex Attack Surface

REST mostly concerns HTTP semantics and JSON validation. SOAP requires teams to secure:
• XML parsing and associated XXE and XML DoS risks
• strict WSDL and XSD contracts
• SOAP headers and routing (SOAPAction)
• WS Security signing and encryption
• stateful or multi step operations

Misconfiguring any one of these layers can expose vulnerabilities that simply do not exist in typical REST JSON APIs.

2. WS Security Is Powerful but Easy to Misconfigure

WS Security adds message signing, encryption, and token handling, but implementing it correctly requires understanding XML canonicalization, key management, and the SAML token structure. Many teams fall back to partial security (e.g., TLS only, no signing or timestamp checks), creating gaps attackers can exploit.

3. Historically Weak Tooling

For years, most scanners focused on REST and web apps. SOAP support was often incomplete, resulting in many SOAP services receiving less continuous testing. WSDL parsing, signature validation and multi step workflow testing were common blind spots.

4. SOAP Lives in Slow Moving, Legacy Environments

SOAP often fronts mainframes or older enterprise systems. These stacks patch slowly, use long release cycles and cannot be redeployed quickly. Vulnerabilities persist longer than in agile REST microservices.

5. SOAP Has Unique Attack Vectors

SOAP introduces security risks that do not appear in REST, such as:

• XML Signature Wrapping
• SOAPAction spoofing
• schema poisoning
• canonicalization exploits

These require specialised knowledge that many modern engineers do not have.

6. REST Is Simply Easier to Secure

REST benefits from mature patterns: JSON validation, OAuth, API gateways, simple stateless design and abundant tooling. SOAP, by comparison, requires managing an entire XML and WS Security ecosystem, which increases complexity and the likelihood of misconfigurations.

Why Traditional SOAP Security Tools Fail: Legacy Scanners, High False Positives & Gaps

Most organisations still protect SOAP APIs with a mix of manual pentests and legacy DAST scanners built initially for websites. These approaches worked a decade ago, but they are no longer sufficient for systems that now handle high value transactions and face increasingly automated attacks.

1. Coverage Gaps with Legacy Scanners

Traditional DAST tools were retrofitted for SOAP. Many still struggle with WSDL parsing, WS Security policies, XML canonicalisation and multi step workflows. A 2025 industry review noted that most legacy scanners “are unable to support SOAP API security testing,” forcing teams to resort to expensive manual testing late in the release cycle. This leads to blind spots and slow detection.

2. High False Positives and Manual Overhead

Older SOAP tools often flood teams with unverified findings (like “possible SQL injection” without proof) that require manual triage. Tools like WS Attacker are powerful but too specialised for routine developer use. As a result, many teams test SOAP APIs infrequently, often only before major releases, leaving long windows during which vulnerabilities go unnoticed.

3. Static, Rules Based Defenses Are Easy to Evade

XML firewalls, WAF rules and schema checks catch known issues, but attackers now mutate payloads, abuse parsing behaviour and chain logic flaws that signature based tools cannot detect. Variants of XXE, XML wrapping or SOAPAction spoofing easily bypass outdated rule sets.

4. SOAP Systems Change Slowly, Attackers Move Fast

SOAP typically sits on top of legacy systems that cannot be patched or redeployed quickly. When security tools do not integrate with CI/CD or fail to test continuously, organisations inherit long lived vulnerabilities that attackers can repeatedly exploit.

Today’s threat landscape requires continuous, automated and context aware testing, especially for mission critical SOAP services. Security cannot depend on annual pentests, static scanners or fragile XML rule sets.

This is where modern platforms such as Levo.ai provide a step change. By analysing real API traffic, auto discovering SOAP endpoints, generating schema aware tests and integrating directly into CI/CD pipelines, Levo enables teams to detect issues early, reduce false positives and maintain continuous assurance even for legacy SOAP systems that rarely change.

How Levo.ai Improves SOAP API Security Testing: Continuous Discovery & Schema-Aware Testing

Modern SOAP environments need continuous, intelligent security, not the manual, point in time testing that legacy tools rely on. Levo.ai closes this gap by delivering automated discovery, context aware testing, and runtime intelligence specifically built to handle SOAP’s complexity (WSDLs, XML schemas, WS Security, and stateful workflows).

Levo strengthens SOAP API security testing end to end by : 

1. Continuous Discovery of SOAP Endpoints

Levo automatically identifies every SOAP service in an environment by analysing real traffic with lightweight eBPF sensors, scanning repositories for WSDLs and monitoring CI/CD metadata. This eliminates hidden or forgotten SOAP endpoints and gives security teams a complete, continuously updated API inventory.

2. Schema Aware, Context Driven Test Generation

Instead of blasting generic payloads, Levo reads WSDLs, XML schemas and real traffic patterns to generate intelligent, structure aware tests. It mutates fields based on expected types, probes nested XML structures for XXE or parsing weaknesses and models business logic from actual usage. This approach uncovers deep SOAP specific flaws such as XML wrapping and schema poisoning with far fewer false positives.

3. Native Handling of WS Security and Authentication

Most scanners break when SOAP uses WS Security. Levo does not. It can sign or encrypt requests, replay UsernameToken or SAML based flows and navigate multi step auth sequences automatically. This ensures complete coverage of real, authenticated SOAP operations without manual scripting.

4. Shift Left and Continuous Testing for SOAP

Levo hooks directly into CI/CD pipelines, so security tests run whenever a WSDL changes, a service is redeployed, or a dependency is updated. Scheduled scans run in staging or production like environments, catching issues early rather than during infrequent audits.

5. Runtime Anomaly Detection for SOAP Traffic

By observing live SOAP traffic, Levo detects unusual XML structures, unexpected callers or behavior consistent with XXE, XML DoS or signature bypass attempts. This provides real time protection for SOAP services that cannot be patched quickly.

6. Safe Testing for Fragile Legacy Systems

Levo bases its tests on real traffic and schema behaviour, reducing the risk of overloading old SOAP servers or triggering crashes with malformed XML. This makes continuous testing viable even for mission critical legacy integrations.

7. Developer Ready Findings and Guided Fixes

Every finding includes the exact SOAP request, the impacted schema field, reproducible payloads and remediation guidance mapped to the relevant code. This shortens resolution time and removes the need for specialised SOAP security expertise.

8. Addresses Core Gaps in Traditional SOAP Tools

Levo solves the long standing limitations of legacy SOAP scanners: it provides full coverage through discovery and WSDL ingestion, dramatically reduces false positives through context aware testing, enables frequent testing via CI/CD integration and adds runtime visibility that older tools never offered. The result is a modern, low noise, continuous security posture for SOAP APIs.

Conclusion: How to Secure SOAP APIs in 2026 with Continuous, Automated Security Testing

SOAP APIs may belong to an earlier generation of web services, but they continue to power some of the most sensitive and business critical workflows in finance, healthcare and enterprise integration. Their strict schemas, WS Security features and reliability make them invaluable, yet the same complexity also creates blind spots that attackers increasingly exploit. 

Effective SOAP security requires more than annual pentests or legacy scanners; it demands precise input validation, strong authentication and message protection, rigorous access control and continuous, context aware testing that matches the pace of modern development.

This is where modern API Security Testing tools like Levo.ai materially change the equation. By analysing real runtime traffic, automatically discovering SOAP endpoints and generating schema aware tests, Levo removes the manual burden that has historically hampered SOAP security efforts. Its ability to handle complex auth flows, detect anomalies in live XML traffic and test safely against fragile legacy systems provides a level of depth that traditional tools rarely achieve. 

For organisations that depend on SOAP, adopting a runtime informed, continuous testing approach ensures that even long lived or legacy SOAP services maintain strong, up to date security posture. With the right strategy and modern tooling, SOAP APIs can remain reliable workhorses, without becoming hidden liabilities.