SOAP API security is the practice of protecting XML-based web service messages, credentials, operations, and backend resources from interception, tampering, unauthorized access, parser attacks, replay, and resource exhaustion. The most important point is that HTTPS alone protects the connection, while SOAP applications still need secure XML processing, authorization, and—where the architecture requires it—message-level protections such as WS-Security.
SOAP remains common in banking, insurance, healthcare, telecom, ERP, government, B2B integration, and long-lived enterprise systems. It is mature and interoperable, but its XML processing model and security extensions are complex enough that unsafe defaults, loose parser configuration, or incorrect signature handling can create serious gaps.
What SOAP API security needs to protect
SOAP 1.2 defines an XML-based messaging framework. A SOAP envelope may contain headers, security tokens, addressing data, routing information, and an application payload in the body. Depending on the environment, intermediaries may process headers before the message reaches the final service.
Transport channel
Protect client-to-server links with TLS and validate server certificates. Use mutual TLS where service or partner identity at the connection layer is appropriate.
XML message
Parse untrusted XML safely, validate structure, and prevent XXE, entity expansion, oversized documents, and schema-fetching attacks.
Security semantics
Validate tokens, timestamps, message IDs, signatures, encryption, and exactly which elements are protected when WS-Security is used.
Business action
Authorize the operation, object, tenant, and sensitive fields; limit automation and observe what data the service returns.
Transport security vs message security
TLS and WS-Security solve different problems. TLS protects data while it travels between two TLS endpoints. If a reverse proxy terminates TLS and forwards the SOAP message internally, transport confidentiality ends at that proxy unless a second protected connection is used. WS-Security can provide integrity, confidentiality, and token binding to the SOAP message itself, including selected XML elements.
| Control | Protects | Useful when | Does not replace |
|---|---|---|---|
| TLS / HTTPS | Connection confidentiality, integrity, server authentication | Almost every production SOAP deployment | Application authorization, XML hardening, message validation |
| mTLS | Client/workload identity at the TLS layer | Partner or service-to-service trust | Per-operation and per-object authorization |
| WS-Security signature | Integrity/authenticity of selected message content | Message passes through intermediaries or requires end-to-end integrity | Safe XML parsing and business authorization |
| WS-Security encryption | Confidentiality of selected message content | Message confidentiality must survive intermediary hops or storage | Key management and transport hardening |
OASIS WS-Security 1.1.1 describes SOAP extensions for security tokens, message integrity, and confidentiality. The specification itself also makes clear that these mechanisms are building blocks rather than a complete security solution. That is the right operational mindset: do not add WS-Security mechanically; design the security profile around real trust boundaries.
A practical SOAP API threat model
| Risk | Example | Primary defenses |
|---|---|---|
| XXE / external resource loading | DOCTYPE or external entity causes file access or server-side network requests. | Disable DTD/external entities, external DTD/schema access, and XInclude; use secure parser settings. |
| XML entity expansion / parser DoS | Recursive entities or extremely complex XML consume CPU/memory. | Disallow DTDs, cap depth/size, parser resource limits, rate limits. |
| Signature wrapping | Signature is valid for one element but application processes an attacker-controlled duplicate. | Trusted schema validation, strict ID handling, exact signed-element binding. |
| Replay | A valid signed payment message is sent again. | Timestamp/expiry, unique message ID or nonce, replay cache, idempotency. |
| Broken operation authorization | Authenticated partner invokes a privileged administrative SOAP action. | Deny-by-default operation authorization and least privilege. |
| Broken object authorization | Caller changes account/customer identifier in SOAP body. | Server-side ownership/tenant checks on the requested object. |
| Sensitive response exposure | Valid service response returns unnecessary customer or credential data. | Response minimization, property authorization, runtime response inspection. |
SOAP API security best practices
1. Require TLS and verify certificates correctly
Use HTTPS for production SOAP traffic. Validate the certificate chain, hostname, expiry, and trust anchor. Avoid “temporary” code paths that disable verification for internal services. For partner or service-to-service environments, mTLS can provide a strong workload identity signal, but it should feed authorization rather than bypass it.
2. Authenticate callers with an explicit trust model
SOAP deployments use many identity patterns: mTLS, WS-Security UsernameToken, X.509 tokens, SAML tokens, Kerberos, OAuth gateways, or organization-specific partner credentials. Define which identity source is authoritative and how it maps to the application principal. Reject ambiguous combinations rather than accepting whichever credential happens to parse.
If a legacy UsernameToken profile is required, protect the channel with TLS, follow the profile correctly, and avoid treating password-equivalent material as safe merely because it is embedded in XML.
3. Authorize the SOAP operation and the target object
Authentication is only the first step. The service should authorize the requested operation—such as CloseAccount, SubmitClaim, or UpdateCustomer—and then validate whether the caller may act on the specific object or tenant referenced in the SOAP body.
<UpdateCustomerRequest>
<CustomerId>C-4831</CustomerId>
<Email>new@example.test</Email>
</UpdateCustomerRequest>
Server checks:
1. Is the caller allowed to invoke UpdateCustomer?
2. Is C-4831 inside the caller's tenant / portfolio?
3. May this caller change the Email field?
4. Does the update satisfy business approval rules?4. Harden every XML parser that sees untrusted SOAP
OWASP's XXE guidance recommends disabling DTDs entirely where possible. Also disable external general entities, external parameter entities, external DTD loading, external schema and stylesheet access unless explicitly allowlisted, and XInclude when it is not required. Enable secure-processing and entity-expansion limits offered by the platform.
Do not assume one “front door” parser is enough. SOAP messages can be parsed by gateways, ESBs, application frameworks, logging enrichers, signature libraries, XSLT transforms, schema validators, or custom integration code. Every parser path needs safe settings.
5. Validate against trusted, local schemas
XSD validation can reject unexpected structure, element placement, and types before business logic runs. Use schemas that are packaged and version-controlled with the service or resolved through a strict local catalog. Do not allow a request to cause arbitrary remote schema retrieval.
Schema validation is not business validation. After the XML is structurally valid, enforce ranges, lengths, identifier formats, field combinations, data ownership, and business state.
6. Limit XML size, depth, element count, and parsing work
SOAP messages can be weaponized without violating XML syntax. Set limits for request body size, element depth, attribute count, text length, list size, namespace complexity, and attachment size. Protect CPU and memory budgets so one request cannot consume disproportionate parser or transformation resources.
Rate-limit by client identity and operation cost, not only by IP. A report-generation SOAP operation may be far more expensive than a simple status lookup.
7. Validate signatures before trusting signed data
When XML signatures are used, verify the cryptographic signature with an expected trust anchor and then bind application processing to the exact signed element. Avoid broad DOM lookups that can find a different element with the same name after signature validation. Duplicate identifiers should be rejected.
This is the core defense against XML signature wrapping: application code and signature code must agree on the same node. Security decisions should never rely on “the first element named X” or a loose XPath after another element was actually signed.
8. Sign the fields that establish freshness and identity
If timestamps, message IDs, action names, destinations, or token references influence replay and routing decisions, they should be protected consistently with the security profile. An unsigned timestamp next to a signed body can create a false sense of freshness because an attacker may be able to alter the timestamp independently.
9. Prevent replay explicitly
A cryptographically valid SOAP message may still be dangerous if it can be replayed. Use a bounded timestamp window and unique message ID/nonce, store recently seen identifiers in a replay cache, and design state-changing operations to tolerate retries safely where possible.
For financial or high-value workflows, combine message replay protection with application-level idempotency. A duplicate transport retry and a malicious replay can look similar to the business system.
10. Keep WS-Security policies minimal and interoperable
Complex XML security profiles are hard to test and maintain. Use only the token types, signature algorithms, encryption algorithms, canonicalization behavior, and key references that your trust model needs. Reject deprecated algorithms and unexpected security-header combinations. Test with every supported partner/client stack.
11. Protect SOAPAction and operation routing
Some SOAP stacks and gateways use the HTTP SOAPAction header, the SOAP 1.2 action parameter, WS-Addressing Action, body element, or a combination of signals to route a request. Make sure security policy and backend dispatch resolve the operation consistently. An attacker should not be able to present one operation to the gateway while causing a different backend method to execute.
12. Minimize SOAP faults and error leakage
SOAP Faults should be useful to clients without revealing stack traces, database errors, internal paths, secrets, or detailed authorization logic. Keep deep diagnostics in protected logs. Normalize parser/security failures so attackers cannot easily use tiny differences to enumerate internal behavior.
13. Secure attachments and MTOM/XOP flows
If the service accepts attachments, apply independent limits and content validation. Do not assume the XML envelope's size limit protects a large MIME attachment. Verify file type based on actual content where appropriate, scan untrusted uploads when the use case warrants it, and ensure authorization covers the attachment as well as the SOAP body.
14. Inventory WSDLs, operations, versions, and partner exposure
Maintain an inventory of active SOAP endpoints, WSDL versions, operations, partner/client identities, certificates, security profiles, and data classifications. Retire obsolete endpoints rather than leaving old WSDL operations reachable behind “legacy” routes. Improper inventory is as dangerous for SOAP as for newer APIs.
How to use WS-Security safely
WS-Security is appropriate when the message itself needs integrity, confidentiality, or portable security tokens independent of a single TLS hop. OASIS defines mechanisms for security headers, tokens, XML signatures, XML encryption, timestamps, and related processing.
Define the protected parts
Document which body/header elements must be signed or encrypted. Verify the policy rejects partially protected messages that look superficially valid.
Pin trust correctly
Validate certificate/token chains against the intended partner or identity provider. Do not trust arbitrary keys embedded in the message.
Validate freshness
Protect timestamp and message identifiers, enforce clock-skew/expiry policy, and cache IDs to reject replays.
Test canonicalization and transforms
Use a narrow set of approved algorithms and test interoperability and wrapping defenses with adversarial messages.
A simpler profile is usually safer than a feature-rich one. Every optional transform, token form, or trust path increases the number of cases the implementation must validate correctly.
XML hardening checklist for SOAP parsers
| Control | Recommended behavior | Risk if missing |
|---|---|---|
| DOCTYPE | Disallow unless a documented legacy requirement exists | Entity definition and expansion attack surface |
| External entities | Disable | File disclosure, SSRF, internal scanning |
| External DTD/schema fetch | Disable or strict local allowlist/catalog | SSRF and dependency on attacker-controlled resources |
| XInclude | Disable unless explicitly needed | Unexpected local/remote resource inclusion |
| Entity expansion | Bound or eliminate via DTD disablement | Memory/CPU exhaustion |
| Document size/depth | Bound to business need | Parser and application DoS |
SOAP gateways, WAFs, and runtime monitoring
SOAP is often deployed behind an ESB, API gateway, reverse proxy, load balancer, or XML firewall. These layers can enforce TLS, client certificates, schema policy, rate limits, and coarse operation access. They are valuable, but they do not replace application authorization or secure parser configuration.
Monitor both requests and responses. Useful signals include operation name, authenticated partner/user, certificate subject, WS-Security token/signature result, XML validation failures, message size, SOAP Fault patterns, response size, sensitive-data indicators, replay rejections, and unusual access to many object IDs.
For related controls, see Ammune's guidance on API sensitive data exposure, runtime API security, and operational API security blind spots.
Where Ammune can fit
Ammune describes runtime capabilities including API discovery, request and response inspection, behavioral analysis, sensitive-data visibility, Layer 7 protection, and SIEM-ready evidence. For SOAP environments, validate compatibility with the exact deployment path, XML/SOAP processing mode, encryption/signature placement, and any gateway or ESB that changes messages before they reach the application.
Common SOAP security mistakes
- Assuming HTTPS solves SOAP security. It does not enforce operation authorization or safe XML parsing.
- Enabling WS-Security without a policy. Complex headers do not help if the application trusts the wrong token, element, or key.
- Using default XML parser settings. Legacy frameworks can expose DTD/entity or remote-resource behavior.
- Validating a signature but reading a different XML node. This is the essence of signature-wrapping risk.
- Fetching schemas from request-controlled locations. Schema validation should not become SSRF.
- Using mTLS as blanket authorization. A partner certificate should not authorize every operation or customer record.
- No replay cache for signed state-changing messages. Integrity does not imply uniqueness.
- Logging full security headers. Tokens and credential material can leak into logs.
SOAP API security implementation checklist
- Require TLS; use mTLS when workload/partner identity requires it.
- Define one authoritative identity model and reject ambiguous credentials.
- Authorize each SOAP operation and target object/tenant.
- Disable DTDs and external entities wherever possible.
- Disable external DTD/schema/stylesheet retrieval or use strict local catalogs.
- Disable XInclude unless explicitly required.
- Set XML body, depth, element, attachment, and processing limits.
- Use trusted local XSDs and add semantic validation after schema validation.
- If using WS-Security, define exactly what must be signed/encrypted.
- Validate signatures against trusted keys and bind application logic to the exact signed node.
- Reject duplicate IDs and unexpected security-header combinations.
- Protect timestamp, message ID, action, and routing fields consistently.
- Use freshness windows, replay caches, and application idempotency for sensitive operations.
- Align SOAPAction/WS-Addressing/body dispatch so policy and backend execute the same operation.
- Return safe SOAP Faults and keep diagnostics server-side.
- Secure attachments independently from the XML envelope.
- Inventory WSDLs, versions, owners, partners, certificates, and deprecated operations.
- Monitor request and response behavior for abuse, data leakage, and parser/security failures.
Conclusion
SOAP is mature, but secure SOAP is not simply “HTTPS plus XML.” Its real security model spans the transport, XML parser, token/signature layer, operation dispatcher, business authorization, and runtime controls. The highest-value improvements are often straightforward: remove dangerous XML features, reduce trust ambiguity, authorize every action and object, and make replay/resource limits explicit.
Where WS-Security is required, keep the profile narrow and test exact signed/encrypted elements rather than trusting a valid-looking security header. That produces a service that is both interoperable and defensible.
Technical references
SOAP API security FAQ
Is SOAP secure by default?
No. SOAP defines an XML-based messaging framework, not a complete security policy. Production services still need TLS, authentication, authorization, hardened XML parsing, resource limits, safe WS-Security configuration where used, and runtime monitoring.
When should SOAP use WS-Security?
WS-Security is useful when message-level integrity, confidentiality, security tokens, or protection across intermediaries is required. If transport security alone meets the threat model, adding WS-Security may be unnecessary complexity. The choice should follow the trust boundaries and interoperability requirements.
Does HTTPS replace WS-Security?
HTTPS protects the transport connection between two TLS endpoints. WS-Security can protect selected message content and associate security tokens with the SOAP message itself. They solve different problems and are often combined when end-to-end message protection is required across intermediaries.
How do you prevent XXE in SOAP services?
Use a hardened XML parser: disallow DTDs where possible, disable external general and parameter entities, prevent external DTD and schema fetching, disable XInclude unless explicitly required, and enforce parser resource limits. Never parse untrusted SOAP XML with unsafe default settings.
What is XML signature wrapping in SOAP?
XML signature wrapping abuses differences between what was cryptographically signed and what application code later processes. Defenses include trusted schema validation, strict ID handling, validating the signature before using security-relevant fields, and binding application logic to the exact signed element rather than searching loosely by tag name.
Should SOAP services validate against XSD?
Schema validation is useful for structure and type enforcement, but it is not sufficient by itself. Use trusted local schemas, prevent external schema retrieval, and add semantic validation for ranges, identifiers, authorization, tenant scope, business rules, and data size.
How can SOAP replay attacks be reduced?
Use fresh timestamps, expiration windows, message IDs or nonces, replay caches, and transaction-level idempotency where appropriate. If signatures are used, protect the timestamp and identifier fields so an attacker cannot alter freshness data independently.
What should be logged for SOAP security?
Log the service and operation, authenticated identity, authorization result, SOAP fault category, message size, validation failures, signature or token failures, latency, correlation identifiers, and abnormal response behavior. Avoid storing raw passwords, tokens, private keys, or unnecessary sensitive XML payloads.
Evaluate SOAP security across the real service path
Validate parser hardening, WS-Security behavior, operation authorization, response exposure, and runtime controls through the same gateways, ESBs, proxies, and services used in production.