Exception Shielding
| Retired Content |
|---|
The Web Service Software Factory is now maintained by the community and can be found on the Service Factory site. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. Retired: November 2011 |
In Windows Communication Foundation (WCF), unknown exceptions are not sent to the client application to prevent details of the service implementation from escaping the secure boundary of the service. This is controlled through the includeExceptionDetailInFaults property in the Web.config file. By default, this property is set to false.
Note
The includeExceptionDetailInFaults configuration setting is used only for unknown or unhandled exceptions. It does not have any effect on known exceptions, such as the FaultException type available in WCF.
Exception shielding helps prevent a Web service from disclosing information about the internal implementation of the service when an exception occurs. The following forces explain why you should use exception shielding:
- Exception details may contain clues that an attacker can use to exploit resources used by the system.
- Information related to anticipated exceptions needs to be returned to the client application.
- Exceptions that occur within a Web service should be logged to support troubleshooting.
Only exceptions that have been sanitized or are safe by design should be returned to the client application. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service's inner workings. You should use the Exception Shielding pattern to sanitize unsafe exceptions by replacing them with exceptions that are safe by design. For more information about the Exception Shielding pattern, see Exception Shielding.