Platform Features
By Need
By Industry
Partner Program
Our Partners
Key Alliances
Resource Center
Key Takeaway
Simple Object Access Protocol, better known as SOAP, is a standards-based messaging protocol specification. Introduced in 1998, SOAP and a handful of other web standards became the foundation for a generation of enterprise technologies. SOAP APIs are especially handy when it’s necessary for a server and client to exchange data in a structured format, as SOAP messages are built in extensible markup language (XML).
Thinking about SOAP APIs brings to mind a middle school taunt along the lines of “The 90s called. They want their pants back.” Revolutionary in its day, the technology can sometimes now feel dated. Yet, the Simple Object Access Protocol (SOAP) has exhibited more staying power than many of its detractors would like to admit. If you’re involved in enterprise architecture or application integration, it pays to know a bit about SOAP APIs—where they came from, what they do, where they can be effective, and the vulnerabilities they can potentially create.
SOAP is a standards-based messaging protocol specification. SOAP messages exchange structured information using XML as its message format. In a nutshell, a SOAP message is essentially an XML document that consists of four different elements:
With SOAP, an application can invoke a web service, send or retrieve data, or issue a procedure call. A SOAP message travels using application layer protocols like Hypertext Transport Protocol (HTTP), though it can also run on Simple Mail Transfer Protocol (SMTP), Java Message Service (JMS), and others.
y
To understand the importance of the Simple Object Access Protocol (SOAP), it’s necessary to know what came before it and the problems its creators set out to solve. SOAP enables two or more applications, built in any language and running on any platform to exchange data and procedure calls across virtually any kind of network. This may not seem so special in 2022, but there was a time when the very idea of such interoperability would have seemed like science fiction.
Getting two or more computer systems to communicate and interoperate is a challenge that goes back at least to the early 1960s. And, while many innovative developments made it incrementally easier to achieve this goal, by the 1990s, many industry insiders had reached the conclusion that a radical change was needed. Interfaces between applications were either custom-coded or built using cumbersome proprietary middleware products. Companies spent fortunes and person-years managing these fragile connections and buying connector sets.
The answer was for the major industry players to come together and agree upon a set of open standards for application integration, data exchange, and interoperation. By 1998, these standards had come into existence and were ratified by the Internet Engineering Task Force (IETF). In addition to SOAP, these so-called “web services standards” included Web Services Description Language (WSDL), which describes how a SOAP web service works, and Universal Description Discovery and Integration (UDDI), which is a format for a SOAP web service directory.
SOAP and its accompanying web services standards became the foundation for an entire generation of dominant enterprise technologies. The web services standards were the basis for the massive, entirely new Microsoft .NET framework, the Oracle Aquasoft platform and portfolio, IBM’s WebSphere integration platform and portfolio, SAP NetWeaver, and others. They represented a profound revolution in software development, application integration, and enterprise architecture.
SOAP messages are built in the Extensible Markup Language (XML). The SOAP standard specifies the XML schema used to create a SOAP message. This includes the “envelope” for the SOAP message, which defines the message structure and destination. The SOAP XML schema also includes encoding rules that represent data types, as well as a convention for representing procedure calls and responses.
SOAP is useful in a variety of situations. It is good when synchronous processing is occurring, perhaps coupled with the need to invoke certain APIs subsequently. SOAP APIs are handy when it’s necessary for a server and client to exchange data in a structured format. SOAP is also effective for the seamless processing of stateful operations, i.e., when an application needs to maintain the state from one request to another.
In some cases, there may be no choice but to use SOAP, e.g., when it’s the default integration protocol for a packaged application. There is also the likelihood that you’ll encounter a legacy and shadow SOAP API that was deployed by a former employee.
Transfer protocols are based upon the use of rules or instructions for data exchange over the Internet. Currently, the protocol uses low-level protocols including IPv4 that simply transmits the packets to the other site. Some higher transfer layers like TCP assure data delivery. Finally, the web browsers can use applications level protocol for communicating and storing data on servers without actually determining the connection itself. SOAP supports several transfer protocol, including specialized low-level ones. SOAP allows communication via TCP protocol – an intermediate level data exchange system working via an Internet network.
Despite the stigma that SOAP carries of being an outdated technology, its longevity and long track record of use would actually imply that the protocol is quite effective. Let’s take a look at a few of the notable benefits of using SOAP:
Due to the fact that SOAP is rooted in the XML format, it is interoperable with all programming languages and provides a standardized way of exchanging data between different software systems. This means that developers can create applications that can access data from different sources.
With WSDL, for example, a developer gets the information he or she needs to develop and implement a SOAP API with relative ease. SOAP’s multiple extensions, like WS Addressing, WS Security, and WS Federation, are also helpful as pre-built app components.
SOAP is more secure than HTTP because it uses SSL encryption to protect data transmission. In contrast, REST APIs don’t feature security and extension capabilities as SOAP APIs do. Security depends upon the API’s own architectures.
On the downside, SOAP has shown some pretty clear weaknesses when compared to some of the newer generation protocols. Let’s review some of the key disadvantages of using SOAP vs protocols like REST or GraphQL:
When compared to it’s RESTful alternative, the SOAP syntax tends to be challenging. For instance, performance can be an issue due to the fact that parsing XML data can be CPU and memory intensive.
And, while SOAP is theoretically vendor-neutral, implementing it often involves committing to a stack, such as Microsoft, which not everyone wants to do.
SOAP API vulnerabilities include Denial of Service (DoS) attacks, XML injection (XXE), SQL injection, command injection, and more. SOAP is also vulnerable to spoofing and Man-in-the-Middle (MiTM) attacks. Web service security tools can mitigate many of these risks.
Use of SOAP and the web services standards has been in decline since the emergence of Representational State Transfer (REST) as the primary basis for APIs, data exchange, and application integration. There’s an idea that REST “replaced” SOAP. This is true, in a limited way, but it’s worth noting the differences between the two.
SOAP and GraphQL are two different protocols that are used to communicate with web services. They both have their own advantages and disadvantages but they are both widely used today. SOAP is a is a request-response protocol that uses XML for the request and response.
GraphQL, on the other hand, has been gaining popularity over the years because it offers more flexibility than SOAP. One of the most notable advantages is that it provides a way to query data from multiple sources without having to use multiple APIs. It also allows for better performance because it doesn’t require XML parsing or serialization.
SOAP integrates the WS-Security functionality. Using these protocols, we can determine security measures in transactions and provide privacy guidelines for data integrity in a transactional environment. A further advantage is that it supports encrypted and cryptography signed documents. WS-Security allows your message to not just have HTTPS encryption but also have authenticating data in a message. It must also ensure that the data whose transits outside the HTTPS protocol are retrieved only by the correct processing on that server and not by the correct server itself.
The REST API only supports HTTP security methods. If applications send messages using an HTTPS connection then this message can be secured only by HTTPS communication. Meaning, the message is encrypted only at the time of transport from customer to services. It works well for public websites. Because REST APIs don’t feature security capabilities and extension capabilities as SOAP APIs do, security depends upon the API’s own architectures. A REST API can have a specific security mechanism for allowing only authenticated users to access them.
Aging but still vital, SOAP APIs have a role to play in modern application integration and interoperation. It will likely continue to serve as a critical element of enterprise architectures for a generation to come. With that said, the first step to protecting SOAP APIs is finding out where they are. Considering how long many of them have been deployed, it’s not farfetched to think that many have transitioned into shadow APIs. The employees who originally deployed these APIs have since moved on or retired, and its highly unlikely that there were developer transition plans in place which audited APIs when the organization experienced attrition.
In order to secure not just these APIs but your entire API estate, you must be able to identify all the APIs you have regardless of configuration or type—including RESTful, GraphQL, SOAP, XML-RPC and JSON-RPC. Noname Security not only helps you inventory these APIs, but we also uncover vulnerabilities, misconfigurations, and potential sensitive data exposure.
Learn more about our comprehensive API Security platform by visiting nonamesecurity.com
What is SOAP? SOAP is an XML-based format used for exchanging information in web service interactions. Simple Object Access Protocol (SOAP) APIs offer several essential features not found in other APIs. For starters, SOAP APIs are language and platform-independent, meaning they can use various transport protocols, including HTTP and HTTPS, unlike REST APIs, which often rely on HTTPS.
SOAP APIs are also highly secure, which makes them ideal for financial institutions and other organizations that deal with sensitive data. You can use SOAP APIs with or without a security platform. Built-in error handling means you can quickly determine the cause of any problems you may encounter with SOAP APIs, which many businesses value.
SOAP is one of the earliest APIs, with the first iteration appearing as XML-RPC in 1998. However, even though SOAP APIs have been around for a long time, they’re still used in certain situations today. For example, the enhanced security of SOAP APIs makes it easier to follow an API security checklist to ensure a secure SDLC management process.
REST or RESTful APIs have become the most popular choice for APIs in recent years because of their simplicity and scalability. You can still use SOAP APIs, but REST APIs may be better for your business, depending on your security needs.
There are several ways to create a SOAP API. If you’re using a specific API management tool, you can find a guide for creating a SOAP API with that software. You can also use the Python programming language to make SOAP API calls.
There’s no single best method for creating SOAP APIs. But no matter how you create your API, following API security best practices is crucial. You can use API security testing to ensure your SOAP API is secure and working correctly.
Banks and web services, like PayPal and UPS, often use SOAP APIs because they’re highly secure and reliable, which helps protect sensitive data. SOAP APIs have robust security features, making them an ideal choice for businesses that prioritize data integrity and confidentiality. These SOAP API examples showcase its application in industries where enhanced security is crucial.
SOAP APIs can be essential for your organization — especially with proper security. To learn more about SOAP APIs and API security, request a demo to see how the Noname API Security Platform works.
In order to keep your organization safe from cybercriminals, you need to learn about, and invest in, robust API security tools.
Guest speaker Forrester Principal Analyst Sandy Carielli discusses her research on application security.
After four long years since the original guidelines were created, the Open Web Application Security Project (OWASP) has now updated their Top 10…
Harold Bell
Harold Bell was the Director of Content Marketing at Noname Security. He has over a decade of experience in the IT industry with leading organizations such as Cisco, Nutanix, and Rubrik, and has been featured as an executive ghostwriter in Forbes Technology Council and Hacker News.
All Harold Bell posts All of Harold Bell's postsExperience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.
Certified for your security needs.
