<p>It seems that anyone can snoop on incoming/outgoing .NET web service SOAP messages just by dropping in a simple SoapExtension into the bin folder and then plumbing it in using:</p>

<pre><code>&lt;soapExtensionTypes&gt;
  &lt;add type="MyLoggingSoapExtension, SoapLoggingTools" priority="0" group="High" /&gt;
&lt;soapExtensionTypes&gt;
</code></pre>

<p>Is there a way to prevent SOAP extensions from loading or to be asked in my app (through an event or some such mechanism) whether it's ok to load ?</p>

<p>@Hurst: thanks for the answer. I know about message level encryption/WS-Security and was hoping not to have to go that road. We have classic ASP clients using the service and that opens a small world of pain. There are SSL certs on the site running the web service but I was kinda hoping that I could discourage the client from tinkering with soap extensions as they have developers who have some ability to 'play'.</p>

I am not sure what you mean by extensions and bin folders (I would guess you are using .NET), so I can't answer about them being loaded etc.
However, note that SOAP is designed to allow intermediaries to read the headers and even to modify them. (Do a search for "SOAP Active Intermediaries").
Judging by that, I expect there to be no reason for a technology to avoid snooping by preventing code from reading the SOAP
.
The proper way to protect yourself is to use "
message-level security
". (This is in contrast to
transport-level security
, such as SSL, which does not protect from intermediaries).
In other words, encrypt your own messages before sending.
One available standard used to implement message-level security mechanisms is the
WS-Security
protocol. This allows you to target the encryption to the payload and relevant headers regardless of transport. It is more complex, but that is how you would go about restricting access.