REST and SOAP APIs are the two most common application protocols that define how to build application programming interfaces (APIs). While they share some similarities, there are critical differences that organizations must understand to secure their REST and SOAP APIs properly.
What is SOAP?
Simple Object Access Protocol (SOAP) is a message protocol that allows applications built with different languages and on other platforms to communicate. Designed to be flexible and independent, SOAP enables developers to add features and functions to SOAP APIs regardless of their language.
While SOAP imposes rules that increase complexity and overheads, resulting in slower load times, the built-in compliance inherent in SOAP offers security benefits that often make it the first choice for enterprise environments.
While organizations can handle SOAP API data requests through any application layer protocol – including HTTP, SMTP, and TCP – return messages must be issued as XML documents, as humans and machines can read this language. Completed SOAP API requests are not cacheable by browsers and, as such, cannot be re-accessed without resending to the API.
What is REST?
Representational State Transfer (REST) is a set of architectural principles used to build APIs. REST APIs, also known as RESTful APIs, use HTTP requests to access and use data, which the client then uses to GET, USE, POST, and DELETE data types. Each HTTP request contains all necessary information, meaning clients and servers are not required to retain data to satisfy the request. While developers typically favor the JSON format, once the REST API receives the request, it can return messages in any of the following formats:
- application/JSON
- application/XML
- application/x-web+xml
- application/x-www-form-urlencoded
- multipart/form-data
The six guiding principles or constraints of RESTful APIs are:
- Uniform Interface – REST APIs apply the principle of generality to the components interface, simplifying the overall system architecture and improving the visibility of interactions.
- Client-Server – Separating the client concerns from the server concerns improves the portability of user interfaces across disparate platforms. Simplifying server components also enables scalability.
- Stateless – Statelessness ensures that all requests from client to server contain all the necessary information to understand and complete the request, meaning the server cannot take advantage of any previously stored context information on the server.
- Cacheable – This constraint ensures that a response labels itself as cacheable or non-cacheable. If the response is cacheable, the client application can refuse the response data later for equivalent requests and a specified period.
- Layered System – This principle prevents components from seeing beyond the immediate layer they interact with.
- Code on Demand (optional) – REST API clients may be able to download and execute code in the form of applets or scripts.
SOAP Security
As we discussed earlier, while slower, SOAP APIs are the more secure API option. SOAP supports Web Services Security (WSS) and Secure Socket Layer (SSL) for enterprise-level data protection, whereas RESTful APIs only support SSL.
WSS is a set of protocols that secures SOAP-based messages by implementing the principles of confidentiality, integrity, and authentication. Simply put, WSS ensures that communication between two applications isn’t interrupted or interpreted by a third party.
WSS secures SOAP-based messages as the receiver requires proof that the sender is whom they say they are. The sender, in turn, must be assured that the recipient cannot deny the message. It also ensures that an unauthorized party does not alter the transferred data.
However, although WSS is built into SOAP APIs, organizations must set up security controls properly to ensure they are protected. SOAP security best practices include:
- Run input validation and configuration
- Implement access control technology
- Configure authentication for all API endpoints
- Implement single sign-on (SSO) technology
REST Security
Securing REST APIs is more complicated. REST APIs don’t have built-in security protections, so organizations must implement access policies to ensure that only the right people can view or modify the data stored on their servers. RESTful API security best practices include:
- Use TLS – To prevent cybercriminals from compromising API keys and authentication parameters, use Transport Layer Security (TLS) to encrypt your data. If a URL begins with HTTPS, then you can implement TLS protection.
- Use OAuth 2.0 – Open Authorization (OAuth 2.0) is a standard that allows a user to access a resource via a third-party application, preventing unauthorized API clients from accessing any sensitive information.
- Implement rate limiting – Rate limiting involves restricting the number of requests a client can make to an API in a specific time window to prevent excessive use and brute-force attack techniques such as DDoS.
- Run content-type checks – Content-type checks define the content clients expect to receive from an API. If a client requests the wrong kind of content, their request is rejected.
- Restrict non-permitted HTTP methods – Specify allowed HTTP methods and restrict any request that doesn’t use them to prevent unauthorized access.
To conclude, RESTful APIs are much simpler than SOAP APIs but are far less secure. REST is used chiefly for public APIs, whereas SOAP is more suitable for private enterprise APIs, which require more protection from cybercriminals.
However, it’s important to remember that both SOAP and REST APIs require dedicated API security tools. Traditional security tools aren’t able to protect APIs from cybercrime. According to research from Salt Security, most organizations still rely on conventional tools such as API gateways and Web Application Firewalls (WAFs) to protect themselves. Considering that 77% of respondents to that same survey said their existing security tools aren’t very effective in preventing API attacks, it’s clear that dedicated API security is sorely needed.
