What a Security Mode Controls
Every WCF binding that supports security exposes a <security mode="..."> setting that decides two things at once: whether messages are protected at the transport layer (like HTTPS or a TCP channel with TLS) or at the message layer (WS-Security headers embedded in the SOAP envelope), and how the caller proves its identity. The five values — None, Transport, Message, TransportWithMessageCredential, and TransportCredentialOnly — are mutually exclusive per endpoint, so choosing the right one up front avoids a painful rework of bindings, certificates, and client credentials later.
Cricket analogy: Choosing a security mode is like a captain deciding whether protection comes from the pitch conditions (transport, like a helmet-friendly bouncy wicket) or from technique itself (message, like Steve Smith's tight defensive grip) — you pick the layer where the safeguard actually lives.
Transport, Message, and Hybrid Modes
Transport mode delegates confidentiality, integrity, and often server authentication to the underlying channel — HTTPS for basicHttpBinding or wsHttpBinding, or a TLS-wrapped TCP stream for netTcpBinding. It is fast because encryption is handled by the OS/network stack rather than by WCF serializing extra WS-Security XML, but the protection only exists point-to-point between adjacent nodes, so if a message hops through an intermediary it becomes plaintext there. Message mode instead wraps the SOAP body and relevant headers with WS-Security encryption and signing using X.509 certificates or other credentials, which means the protection travels with the message end-to-end across multiple hops and works even over plain HTTP transport, at the cost of larger payloads and more CPU-intensive processing.
Cricket analogy: Transport mode is like a stadium's overall security perimeter protecting everyone inside for that one match (protection ends when you leave the ground), while message mode is like Virat Kohli's bat having its own grip tape that travels with him to every ground he plays at.
TransportWithMessageCredential and TransportCredentialOnly
TransportWithMessageCredential is the common hybrid for internet-facing services: HTTPS provides bulk encryption and integrity for the whole channel (cheap and fast), while a message-level credential — typically a UserName token — is embedded in the SOAP header to authenticate the caller without requiring a client certificate. This is the standard choice for wsHttpBinding services that need username/password auth over the public internet. TransportCredentialOnly, by contrast, uses transport-level authentication (such as Windows/NTLM or Basic auth carried over HTTP) but does not encrypt the message body at all, so it is only appropriate on trusted internal networks or when the transport itself is already secured by other means, such as an internal HTTPS reverse proxy.
Cricket analogy: TransportWithMessageCredential is like playing under floodlights (transport, the whole ground is lit) while still requiring each player to show their team ID at the boundary rope (message credential) — both layers work together, seen in IPL accreditation checks.
<bindings>
<wsHttpBinding>
<binding name="secureHybridBinding">
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None" />
<message clientCredentialType="UserName" />
</security>
</binding>
</wsHttpBinding>
<netTcpBinding>
<binding name="secureTcpBinding">
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</netTcpBinding>
</bindings>Security mode "None" disables both transport and message protection entirely — no encryption, no signing, no authentication. It should never appear in a production configuration file; it exists purely for local development and diagnostics on an isolated machine.
- WCF exposes five security modes: None, Transport, Message, TransportWithMessageCredential, and TransportCredentialOnly.
- Transport mode relies on the underlying channel (HTTPS, TLS-wrapped TCP) for point-to-point protection.
- Message mode uses WS-Security to encrypt/sign the SOAP envelope, giving end-to-end protection across intermediaries.
- TransportWithMessageCredential combines HTTPS bulk encryption with a message-level credential like UserName — the standard internet-facing hybrid.
- TransportCredentialOnly authenticates at the transport layer but leaves the message body unencrypted; use only on trusted networks.
- The security mode and its nested clientCredentialType settings must match between client and service bindings or the channel will fail to open.
- Mode "None" must never ship to production.
Practice what you learned
1. Which WCF security mode provides end-to-end protection even when a message passes through an untrusted intermediary?
2. Which security mode is the typical choice for a wsHttpBinding service that needs username/password authentication over the public internet?
3. What is the main risk of using TransportCredentialOnly?
4. Why is security mode "None" considered unsafe for production?
Was this page helpful?
You May Also Like
Transport vs Message Security
A deep comparison of how WCF's transport-level and message-level security mechanisms actually protect data, and the trade-offs between them.
Authentication in WCF
How WCF authenticates callers via clientCredentialType options across transport and message security, including Windows, Certificate, UserName, and IssuedToken.
Securing WCF Endpoints
Practical, end-to-end guidance for locking down a WCF service endpoint — binding choice, behaviors, authorization, and operational hardening.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics