Consider exposing different endpoints.

If you need to support ASMX clients, use basicHttpBinding.

If you are migrating from DCOM, use netTcpBinding.

If you need to support legacy WSE clients, use a customBinding in WCF.

If you require interoperability with non-Microsoft clients, use bindings that are targeted for interoperability.

If your non-Microsoft clients understand the WS* stack, use ws2007HttpBinding or wsHttpBinding.

Consider transport security as your preferred security mode.

Know your authentication options.

Know your authorization options.

Know your binding options.

Choose the right binding for your scenario.

Use WCF auditing to audit your service.

If non-repudiation is important, consider setting the SuppressAuditFailure property to false.

Use message logging for debugging purposes.

Instrument for user management events.

Instrument for significant business operations.

Protect log files from unauthorized access.

Do not log sensitive information.

Protect information in log files.

Use a custom trace listener only when message filtering is needed.

Know your authentication options.

Use Windows authentication when you can.

If your users are in Active Directory but you can’t use Windows authentication, consider using Username authentication.

If you are using Username authentication, use a membership provider instead of custom authentication.

If your users are in a SQL membership store, use the SQL Server membership provider.

If your users are in a custom store, consider using Username authentication with a custom validator.

If your clients have certificates, consider using client certificate authentication.

If your partner applications need to be authenticated when calling WCF services, use client certificate authentication.

If you are using Username authentication, validate user login information.

Do not store passwords directly in the user store.

Enforce strong passwords.

Protect access to your credential store.

If you are using client certificate authentication, limit the certificates in the certificate store.

If you store role information in Windows groups, consider using the WCF PrincipalPermissionAttribute class for role authorization.

If you use ASP.NET roles, use the ASP.NET Role Manager for role authorization.

If you use Windows groups for authorization, use the ASP.NET role provider with AspNetWindowsTokenRoleProvider.

If you store role information in SQL Server, consider using the SQL Server role provider for role authorization.

If you store role information in ADAM, use the Authorization Manager role provider.

If you store role information in a custom store, create a custom authorization policy.

If you need to authorize access to WCF operations, use declarative authorization.

If you need to perform fine-grained authorization based on business logic, use imperative authorization.

If you need to support clients over the Internet, consider using wsHttpBinding.

If you need to expose your WCF service to legacy clients as an ASMX Web service, use basicHttpBinding.

If you need to support WCF clients within an intranet, consider using netTcpBinding.

If you need to support WCF Clients on the same machine, consider using netNamedPipeBinding.

If you need to support disconnected queued calls, use netMsmqBinding.

If you need to support bidirectional communication between a WCF client and WCF service, use wsDualHttpBinding or netTcpBinding.

Use replay detection to protect against message replay attacks.

If you host your service in a Windows service, expose a metadata exchange (mex) binding.

If you don’t want to expose your WSDL, turn off HttpGetEnabled and metadata exchange (mex).

Encrypt configuration sections that contain sensitive data.

Use structured exception handling.

Do not divulge exception details to clients in production.

Use a fault contract to return error information to clients.

Use a global exception handler to catch unhandled exceptions.

Run your service in a least-privileged account.

Use IIS to host your service, unless you need to use a transport that IIS does not support.

Know the tradeoffs involved in impersonation.

Know your impersonation options.

Know your impersonation methods.

Consider using programmatic instead of declarative impersonation.

When impersonating programmatically, be sure to revert to the original context.

When impersonating declaratively, only impersonate on the operations that require it.

When you cannot do a Windows mapping, consider using the S4U feature for impersonation and delegation.

If your WCF service cannot be trusted for delegation, consider using the LogonUser API.

If you have to flow the original caller to the back-end services, use constrained delegation.

If you need to validate parameters, use parameter inspectors.

Use schemas with message inspectors to validate messages.

Use regular expressions in schemas to validate format, range, or length.

Implement the AfterReceiveRequest method to validate inbound messages on the service.

Implement the BeforeSendReply method to validate outbound messages on the service.

Implement the AfterReceiveReply method to validate inbound messages on the client.

Implement the BeforeSendRequest method to validate outbound messages on the client.

Validate operation parameters for length, range, format, and type.

Do not rely on client-side validation.

Avoid user-supplied file name and path input.

Do not echo untrusted input.

If you need to support clients over the Internet, consider using message security.

If there are intermediaries between the client and service, consider using message security.

If you need to support selective message protection, use message security.

If you need to support multiple transactions per session using secure conversation, use message security.

Do not pass sensitive information in SOAP headers when using HTTP transport and message security.

If you need to support interoperability, consider setting negotiateServiceCredentials to false.

If you need to streamline certificate distribution to your clients, consider negotiating the service credentials.

If you need to limit the clients that will consume your service, consider setting negotiateServiceCredentials to false.

Use transport security when possible.

If you need to support clients in an intranet, use transport security.

If you need to support interoperability with non-WCF clients, use transport security.

Use a hardware accelerator when using transport security.

Publish your WCF service metadata only when required.

If you need to publish your WCF service metadata, publish it over the HTTPS protocol.

If you need to publish your WCF service metadata, publish it using secure binding.

If you turn off mutual authentication, be aware of service spoofing.

Avoid plain-text passwords or other sensitive data in configuration files.

Use platform features to manage keys where possible.

Protect sensitive data over the network.

Do not cache sensitive data.

Minimize exposure of secrets in memory.

Be aware that basicHttpBinding will not protect sensitive data by default.

Use appropriately sized keys.

Do not use temporary certificates in production.

If you are using Kerberos authentication or delegation, create an SPN.

Use IIS to host your WCF service wherever possible.

Use a least-privileged account to run your WCF service.

Protect sensitive data in your configuration files.