0

This might be a silly question, but I got into a brief debate with two colleagues at work with regards to security as it relates to SOAP vs REST.

I am of the opinion that there is nothing inherently more secure when using SOAP. Put another way, any security you can apply to a SOAP end point, can be applied to to a REST end point (and vice-verse).

Naturally it breaks down a bit when we move to the client side, where REST very probably has much more "client-client side" things, meaning, for example, JavaScript consumers and such. Security while sitting in the user's browser is of course a bit more of a ...challenge.

SO, can anybody provide a counter example perhaps? Apologies if this should be directed to a security focused group - if that is the case, feel free to nuke the question.

demaniak
  • 3,716
  • 1
  • 29
  • 34
  • Could be just because with REST the end user never knows the actual destination vs SOAP. Which gives hackers an easier approach to do malicious things – Rafael Jan 16 '15 at 06:31
  • Thanks for the input Rafael - could you maybe clarify what you mean with "destination" - I assume you mean the end point URL? – demaniak Jan 16 '15 at 06:39
  • yes that is right. it protects the server filesystem by hiding folder structures. Plus you have more flexibility using more http verbs that can also hide resource data and insure their protection since the server can only interact with the request methods (verbs). – Rafael Jan 16 '15 at 06:41
  • if you want to know more about REST in general i recommend [this book](http://www.amazon.com/REST-API-Design-Handbook-ebook/dp/B00890OBFI/ref=sr_1_1?ie=UTF8&qid=1421390712&sr=8-1&keywords=rest). It covers everything you need to know about rest and differences vs soap – Rafael Jan 16 '15 at 06:45

2 Answers2

0

Your colleagues have a point. REST only supports bindings with bearer tokens, where SOAP also supports so-called holder of key tokens. In the latter case, the client proves to the service it consumes that it requested the token by using the generated intermediate key to encrypt the message. This is an extra protection against token theft.

See this article for more info: http://travisspencer.com/blog/2009/02/what-is-a-proof-key.html

MvdD
  • 22,082
  • 8
  • 65
  • 93
  • Thanks for the article user18044, interesting read. If I understood correctly, this is baked into the low-level SOAP protocols, but functionality is reduced by shortcomings in ( then (2009) current web browsers) to be equivalent of basic auth over SSL. SO there is still a case to be made for Server2Server comms being more secure over SOAP, if I have this right. – demaniak Jan 16 '15 at 08:30
  • Hm, on 2nd thought, this seems to be more related to the SAML protocol than SOAP specifically. [This](http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language#The_use_of_SOAP) seems to indicate you can make SAML requests over SOAP for use in back channel comms, to increase front-channel security. – demaniak Jan 16 '15 at 08:40
  • Just found this [SO](http://stackoverflow.com/questions/853620/secure-web-services-rest-over-https-vs-soap-ws-security-which-is-better) - it was closed (as I expect this one to be), but has some useful information still – demaniak Jan 16 '15 at 08:46
  • I think you are confusing the SAML token format with the protocol. These tokens are used in active clients (service to service) with for example the WS-Tust protocol. BTW, I'm not arguing you should choose SOAP over REST. Your question was if using SOAP had any security benefits over REST. – MvdD Jan 16 '15 at 16:02
0

Ok, from the SO link in the comments, the motor-cycle story seems to clear this up for me nicely.

In a nutshell: WS-Security (which is layered over SOAP) is a standard "thing" whereby the message body (your actual data in a request) can be fully, or partially, encrypted (secured) so that only the correct processor code can decrypt it. This is above and beyond and transport-layer security (SSL).

AFAIK, REST, as it stands today, does not have a similar standard. So you CAN implement similar security for your REST services, but YOU will have to do it. For most cases, REST over SSL is probably sufficient for most people (where most people are the bulk of normal user/consumers).

Bottom line, as I have it, there is still not anything security-wise that SOAP can do, that REST can't. The REST side might just require more work than the SOAP side.

Community
  • 1
  • 1
demaniak
  • 3,716
  • 1
  • 29
  • 34