Reducing Information Disclosure in WCF Data Services

Previously, I wrote an article titled "Reducing Information Disclosure in ASP.NET Web Services".  The article identified steps developers can take to eliminate detailed error messages, stack traces, web service description pages, and WSDLs from their production applications. This article will offer similar recommendations for WCF Data Services.  Since this article builds of the previous one, I will not repeat the background information.

Reference WCF Service
We will use the following WCF service as a starting point.

Here is a successful SOAP request.

The WCF Help Page and WSDL are accessible as shown below.

The following two errors occur when parameters are omitted in the web service call or when we try to divide by zero.

ASP.NET Custom Errors: No Help At All
Unlike ASP.NET web services, exception handling in WCF data services is not the least bit affected by enabling custom errors.  When custom errors are enabled, full stack traces, local file paths, and other information is returned to the consumer.

Explicit Try/Catch Blocks: 100% Effective, But What If You Miss One
Try/Catch blocks are just as effective as in ASP.NET Web Services.  Here's the code.

And the result.

As stated in the ASP.NET Web Services article, there is always a chance that we could miss a try/catch block.  We need some sort of backup solution to catch any exceptions that we miss.

includeExceptionDetailInFaults="false": A Great Backup to Try/Catch Blocks
In WCF Data Services, this functionality seems more complete and it is just as easy to implement as in the last article.  Simply set the "includeExceptionDetailInFaults" attribute to "false" in the "serviceDebug" XML element of the Web.config file.

Stack traces and other detailed error information are now suppressed.

Removing the WSDL and WCF Help Pages
Help pages and the WSDL can easily be removed for WCF services.  The "serviceMetadata" and "serviceDebug" XML elements in the Web.config file have attributes to specifically control these items.

When the appropriate attributes are set to "false", the help page and the WSDL show up as blank pages.

Once this change has been made, it will be necessary to communicate WSDLs or web service signatures with partners through some other channel.

WCF Metadata Exchange (MEX)
There is one additional issue to address with WCF Data Services, and that is to disable the Metadata Exchange (MEX) endpoint.  Clients and attackers can query MEX endpoints to learn about web service signatures and configuration.  For more information about MEX, see the following articles:

• What is a metadata exchange (MEX) binding?
• Publishing Metadata

An example HTTP request and response used to query a MEX endpoint is shown below.

Additionally, an attacker can utilize the WCF Test Client to capture this data and query the service.

This behavior can be disabled by removing the MEX end-point.  In the Web.Config file below, the end-point is commented out.

After the configuration change, the MEX endpoint is no longer accessible.