Debugging tools in production: You’ve got your web service all protected with WSE, so why can just anyone browse to the asmx?

I had an email today from someone asking this question. They have a web service and a client app that use WSE2 to encrypt, sign and otherwise secure their data.

However, they were able to open up the asmx file, the operation and look at raw xml data in a web browser over the web. No authentication, no encryption, no signing. I could see it, too!

What a nightmare after all of the work to secure this data.

The reason for this problem was another case of debugging tools getting deployed to the production web server. Something I tend to rant about occasionally.

In order to browse from their development machine to the web service on a remote web server, they had added

<webServices>
 <protocols>
   <add name=”HttpGet” />
   <add name=”HttpPost” />
 </protocols>
</webServices>

and left them in the web.config when it was deployed to the server.

I was able to guess this pretty quickly since I once learned this the hard way, too. Sadly most of our best lessons are the ones that leave bruises. ðŸ™‚

For some more web.config tricks to hide your web service from public view as well as the wsdl, see this msdn doc on configuring web services for deployment.

Don’t Forget: www.acehaid.org

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

One thought on “Debugging tools in production: You’ve got your web service all protected with WSE, so why can just anyone browse to the asmx?

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

This site uses Akismet to reduce spam. Learn how your comment data is processed.