REST vs SOAP security

It has been long time since I have written blog post regarding REST and SOAP. Anyway this post stems from discussion we had during a session on RESTful Web Services. This post is to put forth my opinion on SOAP vs REST security. Both approaches work, but have their own advantages and disadvantages to interfacing to web services, but it is up to the web developer to make the decision of which approach may be best for each particular case.In nutshell, REST and SOAP have two different approaches on WS security this defines that rest (HTTPS) secures the transmission of the message over the network and provides some assurance to the client about the identity of the server.Their interest in authenticating the client is not in the identity of the computer, but in your identity.

WS-Security offers confidentiality and integrity protection from the creation of the message to its consumption. So instead of ensuring that the content of the communications can only be read by the right server it ensures that it can only be read by the right process on the server. Instead of assuming that all the communications in the securely initiated session are from the authenticated user that each request has to be signed. There you can find nice explanation on this with that popular example necked motorcyclist on MSDN blog ( all know that using SOAP has some additional overhead that is not found in the REST approach, but that overhead also has advantages. First, SOAP relies on XML (Extensible Markup Language) in three ways; the Envelope – that defines what is in the message and how to process it, a set of encoding rules for data types, and finally the layout of the procedure calls and responses gathered. This envelope is sent via a transport (HTTP/HTTPS), and an RPC (Remote Procedure Call) is executed and the envelope is returned with information in a XML formatted document.It is important to note that one of the advantages of SOAP is the use of the “generic” transport. While REST today uses HTTP/HTTPS, SOAP can use almost any transport to send the request, using everything from the SMTP (Simple Mail Transfer Protocol) and even JMS (Java Messaging Service). However, one perceived disadvantage is the use of XML because of its verboseness and the time it takes to parse.When it comes to security, I'm now sort of in to do comparison between REST vs SOAP. Web Services use known protocols, ports, descriptors and methods to access and “expose” back-end or middleware components to the client side. Unfortunately, this means that any Web service is also potentially exposed to underlying vulnerabilities including: 
  • O/S vulnerabilities 
  • Web server (e.g. Apache or IIS) vulnerabilities and attempts at exploit 
  • SQL injections (still, amazingly, a huge problem)
  • Scripting exploits (if applicable)
  • Application server attacks
  • Denial of Service attacks
  • Message monitoring and copying (i.e. for illicit purposes)
  • Message source spoofing (meaning bad guys can pretend to be legit.)
  • Message (payload) manipulation (meaning bad guys can change send data – in transit)
  • Transmission of viruses (in message or as an attachment) 
  • Transactional Attacks
  • Application Program Interface (API) scanning to enable source or recipient address discovery 
  • Code manipulation 
and Lots more. 

This is a big issue. So, what are the differences between SOAP and REST? I have placed some of the known considerations into a table - although this is a brief and cursory examination of the matter.

Most vendors are endorsing or supporting SOAP meaning that security issues will be readily exposed and are likely to be fixed or addressed through countermeasures, patches, etc.
Some SD tool vendors and servers are supporting both REST and SOAP (among other options).

  REST is widely endorsed by developers and has a strong historical foundation; although REST specific security guidance has been limited (there is no “leader” for this, such as the W3C with SOAP).
SOAP messages can be (partially) secured by following/implementing WS-Security (WSS). This allows for integrity and confidentiality controls.
The W3C is also issuing security guidance with respect to SOAP and there is some expectation that WSS will be enhanced both by the W3C and by vendors.
REST, dependent on HTTP, does not support secure messaging directly. HTTPS (SSL or TLS with HTTP) is normally proposed, requiring another port to be opened in the Firewall. Also, this approach can make it difficult to proxy sessions. A number of HTTPS related vulnerabilities are known, across multiple products.
HTTPS is only a point to point solution and (mainly in theory) it can be compromised. Use of longer (e.g. 128 bit or larger) keys limits the likelihood of data interception/decryption.
Both SOAP and REST require many additional security supplements to address all issues (e.g. authentication), beyond simply the protection of message content and integrity.
Perhaps most importantly, most security supplements (including HTTPS) only protect communications and attacks on the server are still a problem.
SOAP formatted XML envelopes and XML in general are prone to manipulation (e.g. “infinite string attacks”). Many XML vulnerabilities and exploits are known.

SOAP, when implementing HTTP transits network firewalls, through port 80 (or 8080) effectively tunnelling through that level of security. This has been touted as a big SOAP benefit for developers who can avoid asking for extra ports to be opened on client/server side firewalls (i.e. for other protocols than HTTP).
However, this is a problem from an infrastructure perspective. The most consistent issue is the difficulty of deciding what to let through and what to block.
Having multiple protocols running over one port makes filtering much harder.
Intrusion Detection/Prevention Solutions (IDS/IPS) are used to examine incoming this traffic in close detail.
But the more complex the traffic, the longer the IDS examination takes (in milliseconds). And, SOAP seems to be quite complex (e.g. multiple headers) and message structure can be contextual.
Decisions would need to be made (in advance) as to a “standard” SOAP header structure, protocols (HTTP is likely to be the only one which systems staff will allow vs. SMTP, for example) etc. to be able to block/pass SOAP messages at the Firewall and at the IDS.
More importantly, when SOAP uses HTTP, there is no built-in way for the Firewall (or an IDS) to know if messages are coming from an authenticated source.
REST is tied to HTTP or HTTPS which means that there is more visibility (e.g. HTTP 1.1) to messages which is an advantage for systems staff who have to configure Firewalls and/or IDS solutions to inspect traffic coming into or leaving the secure perimeter.
This would make it easier to route between multiple Web services.
All of the above are also well understood by IT systems staff, with respect to:
·         Protocol format
·         Port usage
·         Traffic patterns
·         Contextual issues (e.g. when a request seems “normal”) which can be significant if incident intervention is (potentially) needed
An attacker can send a specially crafted SOAP request, which makes use of parameter entities to inflict a denial of service condition on the server. This can drive the server to 100% loading resulting in a DOS condition. This is a known issue with various SOAP compatible servers (patches exist).


Access Control Lists (ACL) can readily be applied to REST traffic (e.g. to restrict POST requests to certain users or IP source addresses). In practice this is considered ineffective.

Local HTTP caching presents security challenges which should be addressable (e.g. through cache clearing) but which will need to be tested.

Logging (for audit trails) is simple with REST as all relevant information is held in the URI.
Potential SOAP exploits are less well understood as usage is still somewhat limited (although growing fast). Solutions are potentially complex. However, the WS-Security standard is an effort to provide a fairly open (hence upgradeable) standard to augment SOAP (e.g. for authentication of senders, protection of message integrity, etc.).
REST operations (e.g. GET, PUT) and associated exploits are quite well understood and documented (e.g. flooding of HTTP GET requests, HTTP GET request with long parameter names triggering overflows, etc.) – as are solutions.

Per item 9, if  GETs are accepted from anyone, some or all POSTs can be blocked. If some POSTs are to be allowed (e.g. by a group of trusted users), Access Control Lists (ACL) can be applied.
There are various ways to do this. However, ACLs require manual maintenance (e.g. IP address changes or user profile changes).
This would also require the creation (and enforcement) of strong developer guidelines to prevent un-managed use of GETs.
SOAP is prone to “array overflow” attacks (similar to a buffer overflow) where a CML request with an overlarge array length is specified to a service provider (resulting in a work space for illicit code execution).

SOAP headers contain information which can be altered in transit (man in the middle) to cause harm (e.g. to point to an invalid file reference).

Security scanners (like an IPS or a Web App Firewall) are needed for comprehensive SOAP/XML message analysis. However, these can be placed in-line with XML accelerators.
"Common" IDS/IPS systems tend to be sufficient for scanning of REST (HTTP) traffic. An XML security scanner may not have any effect on REST traffic (i.e. unless XML is embedded in messages, which is not common for invocation).
SOAP messages include specification of the data type for each of their arguments (e.g. string vs. array-of-string). This makes some types of attack (e.g. SQL injection) more difficult to initiate.

So WS-Security offers more protection than HTTPS would, and SOAP offers a richer API than REST. My opinion is that unless you really need the additional features or protection you should skip the overhead of SOAP and WS-Security. I know it's a bit of a cop-out but the decisions about how much protection is actually justified need to be made by those who know the problem intimately. But the untold story is that both technologies can be mixed and matched.  REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. In comparison, SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.