How clean is SOAP?

The February 2004 issue of
Communications of the ACM
includes an article entitled
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
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.