The February 2004 issue of Communications of the ACM includes an article entitled How clean is the future of SOAP? (sorry, you have to be a member or have a subscription to read the full article). The basic thrust of the piece is that if developers aren’t careful with how they develop SOAP-based applications then security staff will close firewalls to SOAP over HTTP and web services will lose their primary advantage, that of being able to penetrate firewalls on port 80.
I thought we were past all this. I remember having a conversation with someone at Microsoft UK back in 2000 asking about this point and wondering whether it wouldn’t be better to just pick a SOAP port instead of 80. I now realise that that was missing the point really and deploying web services as part of a web server has been one of the factors leading to their ongoing success (or promise depending upon your point of view).
The author of this document can be forgiven for not knowing that SOAP is no longer an acronym that formerly stood for Simple Object Access Protocol and is now just a name - it probably isn’t widely known and is tucked away in the SOAP 1.2 recommendation. However, the link to HTTP was only the most popular mechanism from early on - I seem to remember demos with SMTP some time ago. More recently, most people au fait with the current state of play will see that SOAP is really about the message passing and that the transport is really orthogonal to that.
To claim that web services suddenly expose previously unavailable internal application behaviour to external users seems to ignore the state of the web today. There can’t be many corporate web sites actively engaged in driving revenue that serve only static content these days. Most web sites contain web applications and expose internal application behaviour through a HTML and HTTP GET/POST interface (normally used with a browser). Exposing the same functionality with XML and HTTP GET/POST doesn’t in and of itself make things any less secure.
Developers need to be concerned not only with the code they expose through web services but equally (and perhaps more subtly) with anything they expose through any kind of web server. Similarly, security professionals need to be far more deeply involved in understanding the business processes driving the use of web applications and web services in specific terms than simply considering shutting the firewall to SOAP over HTTP.
To be honest, I’d have expected more stringent peer review of an article published in such a prestigious journal.