Simple Object Access Protocol (SOAP) is an XML-based messaging protocol standardized by W3C that’s popular for its predictability, strict contracts, and strong security features. The protocol is the basis for SOAP APIs: The SOAP protocol defines the rules, and SOAP APIs are the actual implementations of those rules.
Over time, newer options like REST, GraphQL, and gRPC have surpassed SOAP in usage, but many enterprises still rely on SOAP to meet strict interoperability requirements, ACID transaction guarantees, and compliance mandates.
SOAP APIs remain prevalent in banking, insurance, telecom, healthcare, and government organizations, where systems are deeply rooted in legacy enterprise environments. These industries value standardized, contract-driven communication that integrates reliably with existing infrastructure.
Strict regulatory and compliance requirements further reinforce SOAP’s relevance: Its mature security and transactional guarantees help ensure data integrity, auditability, and predictable behavior. Even as organizations modernize or adopt hybrid and cloud architectures, SOAP continues to be used where backward compatibility, compliance assurance, and dependable enterprise integration take precedence over newer, lighter-weight API styles.
Advanced API Security Best Practices [Cheat Sheet]
Download the Wiz API Security Best Practices Cheat Sheet and fortify your API infrastructure with proven, advanced techniques tailored for secure, high-performance API management.
Core components of SOAP architecture
Web Services Description Language (WSDL) defines operations, message formats, bindings, and endpoints, making it possible to generate clients automatically and ensuring interoperability across systems. These are the other core elements of SOAP you should know about:
Envelope: The envelope is the outermost element that marks the beginning and the end of the SOAP message; it includes all message information, making sure that it’s correctly interpreted and validated.
Header: Headers are an optional metadata section that can include things like security tokens, routing information, session data, and transaction details. The header also gives you the flexibility to add custom processing instructions.
Body: The body is the core of the SOAP message. It contains the actual payload or request/response data and follows XML structure to guarantee interoperability.
Fault: A fault is a dedicated element for error reporting, including fault codes, fault strings, and optional detailed error information that can be useful to diagnose issues.
What is API attack surface management?
API attack surface management is focused on discovering, inventorying, analyzing, and continuously monitoring all APIs within an organization’s cloud environment. This enables identification and mitigation of points of exposure that could lead to a breach.
もっと読む
SOAP message structure and XML envelopes
Let’s break down a typical request in a simplified SOAP API example to give you a clearer picture of how the SOAP XML envelope is structured and how the headers and body interact. You can take any SOAP payload and then use any SOAP formatter to make the XML structure easier to read and debug, like below:
<soap:Envelope>
<soap:Header>
<auth>username/password</auth>
</soap:Header>
<soap:Body>
<getCustomerDetails>
<customerId>123</customerId>
</getCustomerDetails>
</soap:Body>
</soap:Envelope>(The server will respond with a similar envelope.)
XML is bulky and strict. These tradeoffs can pay off when you enforce XML Schema Definition (XSD) validation correctly—meaning you validate against a strict schema, disable Document Type Definitions (DTDs) and external entities in your parser, and set resource limits to prevent denial-of-service attacks.
Remember: Schema validation ensures data integrity and blocks malformed requests. Skipping schema validation or leaving risky XML features enabled—such as DTDs, external entities, and XInclude—invites XML External Entity (XXE) attacks, XML bombs (billion laughs attacks), and XML injection attacks.
Watch 12-minute demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
How SOAP APIs work
Before we dive deeper, here’s a quick look at the mechanics of a SOAP API.
SOAP request and response cycle
The process is fairly straightforward but requires validation at every step:
The client constructs a SOAP message using the WSDL contract.
The request is sent through a transport protocol (e.g., HTTP/HTTPS).
The server validates the schema and headers.
The request is run through business logic.
The server provides a SOAP response/fault.
WSDL and service description
As we’ve seen, Web Services Description Language (WSDL) serves as the blueprint: It provides a service description—a structured, machine-readable contract that defines how the service can be accessed and what it offers. This includes key details such as endpoints, available operations, message formats, data types, and bindings.
Through this service description, both the client and server understand exactly how to communicate, ensuring consistency and interoperability. On top of that, development tools can automatically generate client and server stubs from the WSDL file, reducing manual coding effort and minimizing the risk of integration errors.
Transport protocols and binding
SOAP is commonly implemented on top of HTTP/HTTPS, but it can also use SMTP or JMS. There are two binding styles:
Remote Procedure Call (RPC): Treats the message like a method call; good for function-oriented use
Document: Treats the message as a full document; better for complex data exchange
The RPC model has historically caused interoperability issues across platforms. As a result, the WS-I Basic Profile recommends the document/literal wrapped style. This approach has become the de facto standard for building interoperable, tool-friendly SOAP services across vendors and environments.
API security posture management explained
API security posture management, or API-SPM, is a security discipline that focuses on maintaining and proactively improving the security health of enterprise APIs.
もっと読むSOAP API security features
It’s worth repeating that SOAP’s popularity rests on its strong security model. Its key security features include…
WS-Security headers: WS-Security headers add tokens, digital signatures, and time stamps to the message envelope in order to provide security and guarantee authenticity. Timestamps in particular play a critical role in replay protection by defining message freshness windows, allowing recipients to detect and reject duplicated or delayed messages.
Message-level security: XML signatures and encryption provide end-to-end protection, ensuring data integrity and confidentiality even in multi-hop scenarios.
Authentication/authorization: SOAP provides support for username tokens, X.509 certificates, SAML statements, and mutual TLS for robust identity checking.
End-to-end message security: SOAP standardizes message-level security through WS-Security for end-to-end protection—even across intermediaries. REST API can also use message-layer approaches (such as JOSE with JWS for signatures and JWE for encryption), but there's no single, widely adopted equivalent standard with the maturity and interoperability of WS-Security.
SOAP vs. REST, GraphQL, and gRPC
Each API style has unique benefits and drawbacks when it comes to performance, security, and different use cases:
| Feature | SOAP | REST | GraphQL | gRPC |
|---|---|---|---|---|
| Protocol | XML-based; formal WSDL contracts | HTTP + JSON;lightweight, loosely defined so that it can be flexible | Query language with schema validation and strong introspection capabilities | HTTP/2 + Protobuf; efficient binary serialization |
| Performance | Verbose due to XML parsing and schema validation; slower but predictable | Lightweight and fast, especially for CRUD operations | Flexible queries allow targeted data fetching but may add complexity and overhead | Super fast (binary); low-latency |
| Security | WS-Security, XML signatures, encryption | HTTPS, OAuth2/OIDC | HTTPS + query validation, field-level access control, fine-grained permissioning | TLS, authentication plugins, mutual authentication for secure inter-service communication |
| Use case | Regulated industries, enterprise integrations, systems needing strict compliance/reliability/security | CRUD-intensive services; web and mobile APIs | Modern UIs requiring flexible data fetching from multiple data sources, complex queries with schema requirements | Microservices with high performance, intra-company RPCs, low-latency applications, and IoT services |
TL;DR: SOAP's drawback is overhead, but for reliability guarantees (WS-ReliableMessaging, WS-AtomicTransaction), it often excels in enterprise integration scenarios.
SOAP API vulnerabilities and security challenges
XML-specific attacks: XXE, XML bombs, XPath injection, and abuse of schema features
Best practices for prevention:
Set parser limits (memory, CPU, depth).
Disable DTDs/XXE in parsers.
Misconfigurations: Exposed WSDLs, weak WS-Security, and use of plain HTTP instead of HTTPS
Best practices for prevention:
Restrict WSDL access in production.
Validate digital signatures carefully to avoid wrapping attacks.
Watch canonicalization (C14N) to prevent subtle signature issues.
DevSecOps gaps: Skipping schema validation, insecure parser defaults, and risky XML library dependencies
Best practices for prevention:
Enforce schema validation to block malformed requests.
Use streaming parsers for large payloads.
Note: Exposed WSDLs aren’t always a direct vulnerability, but they can leak sensitive info in production environments. Restrict or monitor them accordingly.
API Governance: Best Practices & Solutions
API governance refers to the policies, standards, and processes that guide how APIs are built, managed, and secured.
もっと読むHow Wiz secures SOAP APIs across the development lifecycle
SOAP’s built-in security mechanisms are only as strong as their real-world implementation. In cloud environments, SOAP APIs are often exposed unintentionally, misconfigured, or insufficiently protected, despite having standards like WS-Security available.
Wiz secures SOAP APIs as part of Wiz Cloud, without relying on code-level or parser-specific scanning. Instead, Wiz takes an agentless, runtime, and cloud-context-driven approach to API security, aligned with how SOAP services are actually deployed and consumed in production.
Key ways Wiz Cloud secures SOAP APIs include:
Automatic API discovery: Wiz dynamically discovers SOAP APIs running across your cloud environments by observing traffic, workloads, and exposed services, without reequiring agents or source-code access.
Exposure and attack surface analysis: Wiz identifies publicly exposed SOAP endpoints, internet-facing services, and overly permissive network paths that increase the risk of abuse.
Authentication and authorization risk detection: Wiz detects missing, weak, or misconfigured authentication controls (for example, unauthenticated endpoints or inconsistent enforcement of WS-Security and mTLS).
Configuration and posture risks: Wiz highlights cloud and workload misconfigurations that undermine SOAP security, such as insecure load balancer settings and plaintext secrets.
Ready to see for yourself? Get a demo of Wiz to learn how unified, agentless, risk-prioritized security can boost your SOAP APIs (and your REST, GraphQL, and gRPC APIs too!).
Secure APIs from code to cloud
Book a demo to see how Wiz helps security teams uncover API risks and attack paths in real time.
