拒絕服務
當系統由於無法處理訊息，或者處理訊息的速度極為緩慢而爆滿時，就會發生阻絕服務。
過多記憶體耗用
讀取具有大量唯一本機名稱、命名空間或前置詞的 XML 文件時，會發生問題。 如果您正在使用衍生自 XmlReader 的類別，且您為每個項目呼叫 LocalName、Prefix 或 NamespaceURI 屬性，則傳回的字串會新增至 NameTable。 NameTable 所持有的集合大小一定不會減小，它會建立字串控制代碼的虛擬「記憶體遺漏」(Memory Leak)。
風險降低的方式包括：
衍生自 NameTable 類別並強制執行最大的大小配額 (當配額已滿時，您無法避免使用 NameTable 或切換 NameTable)。
避免使用提到的屬性，並盡量搭配使用 MoveToAttribute 方法和 IsStartElement 方法，這些方法不會傳回字串，這樣就可避免 NameTable 集合太滿的問題。
惡意用戶端將大量授權要求傳送至服務
如果惡意用戶端透過大量授權要求炸滿服務，就可能導致伺服器使用過多的記憶體。
避免方法：使用 LocalServiceSecuritySettings 類別的下列屬性：
MaxCachedCookies：控制時間界限之
SecurityContextToken的上限，而這是伺服器在SPNego或SSL交涉之後快取的上限。IssuedCookieLifetime：控制
SecurityContextTokens的存留時間，而這是伺服器在SPNego或SSL交涉之後發出的存留時間。 伺服器在這段時間內會快取SecurityContextToken。MaxPendingSessions：控制在伺服器中建立的安全對話上限，但是不會針對這些對話處理應用程式訊息。 這個配額會防止用戶端在服務中建立安全對話，由此服務會針對每個用戶端保留對話狀態，但不會使用這些對話。
InactivityTimeout：控制服務將安全對話保留在作用中，而不會從用戶端中接收該對話之應用程式訊息的時間上限。 這個配額會防止用戶端在服務中建立安全對話，由此服務會針對每個用戶端保留對話狀態，但不會使用這些對話。
WSDualHttpBinding 或雙重自訂繫結需要用戶端驗證
根據預設，WSDualHttpBinding 已啟用安全性。 不過，如果透過將 ClientCredentialType 屬性設定為 None 而停用用戶端驗證，則惡意使用者可能在第三個服務上導致阻絕服務攻擊。 可能是因為惡意用戶端可以導向至服務，並將訊息資料流傳送至第三個服務。
若要避免這個情況，請不要將屬性設定為 None。 建立具有雙重訊息模式的自訂繫結程序時，也請留意這個可能性。
稽核事件記錄檔已滿
如果惡意使用者發現已啟用稽核，攻擊者就可以傳送無效的訊息，而造成寫入稽核項目。 如果是因為這個方法而填滿稽核記錄檔，稽核系統就會失敗。
若要減輕這個威脅，請將 SuppressAuditFailure 屬性設定為 true，並使用 [事件檢視器] 的屬性來控制稽核行為。 如需詳細瞭解如何使用事件檢視器來檢視與管理事件記錄，請參閱事件檢視器。 如需詳細資訊，請參閱稽核。
IAuthorizationPolicy 的無效實作可能會導致服務變得無法回應
在錯誤的 Evaluate 介面實作呼叫 IAuthorizationPolicy 方法，可能導致服務無法回應。
避免方法：僅使用信任的程式碼。 也就是說，僅使用您所撰寫並測試過的程式碼，或使用來自可信任提供者的程式碼。 在沒有謹慎的考慮之前，請勿將不受信任的 IAuthorizationPolicy 延伸項目外掛至您的程式碼。 這個做法適用於服務實作中使用的所有延伸項目。 WCF 無法區分應用程式碼和使用擴充點外掛的外部程式碼。
可能需要調整 Kerberos 權杖的大小上限
如果用戶端是許多群組的成員 (大約 900 個群組，不過實際數目會因群組而有所不同)，當訊息標頭的區塊超過 64 KB 時，可能會發生問題。 這種情況下，您可以增加 Kerberos 權杖大小上限。 您也可能需要增加 WCF 訊息的大小上限，以便容納更大的 Kerberos 權杖。
自動註冊將使電腦中的多個憑證具有相同的主體名稱
「自動註冊」是 Windows Server 2003 的功能，可自動對憑證註冊使用者和電腦。 當電腦在需要啟用功能的需求上開啟時，就會自動建立具有預期用戶端驗證用途的 X.509 憑證，而每當新電腦加入網路時，也會將此憑證插入本機電腦的「個人」憑證存放區。 不過，自動註冊會對在快取中建立的所有憑證，都使用同樣的主體名稱。
但後果是 WCF 服務可能無法在使用自動註冊的網域上開啟。 這是因為預設服務 X.509 認證搜尋準則可能不明確，起因則為存在多個具有電腦完整網域名稱系統 (DNS) 名稱的憑證。 某個憑證可能源自自動註冊，而其他憑證可能為自行發行的憑證。
若要避免這個情況，請對「serviceCredentials」使用更精確的搜尋準則，以便參考要使用的確切憑證。<> 例如，請使用 FindByThumbprint 選項，並依照其唯一指紋 (雜湊) 指定憑證。
如需自動註冊功能的詳細資訊，請參閱 Windows Server 2003 的憑證自動註冊功能。
最後幾個用於授權的多個替代主體名稱
在少數情況下，當 X.509 憑證包含多個替代主體名稱，而且您使用替代主體名稱進行授權時，授權可能會失敗。
使用 ACL 保護組態檔
您可以針對 CardSpace 發行的權杖，在程式碼和組態檔中指定必要和選用的宣告。 這樣會造成在傳送至安全性權杖服務的 RequestSecurityToken 訊息中發出相對應的項目。 攻擊者可以修改程式碼或組態以移除必要或選用的宣告，這樣便有可能取得安全性權杖服務，而發出不允許存取目標服務的權杖。
避免方法：需要存取電腦以修改組態檔。 使用檔案存取控制清單 (ACL) 以保護組態檔。 若要讓 WCF 允許從組態中載入此類程式碼，該程式碼必須存在於應用程式目錄或全域組件快取中。 使用目錄 ACL 以保護目錄。
達到服務之安全工作階段數上限
當服務順利驗證用戶端而且是藉由服務建立安全工作階段時，服務會持續追蹤工作階段，直到用戶端取消服務或工作階段到期為止。 每個建立的工作階段都不利於服務之同時作用中工作階段的數量上限。 達到這個限制時，將會拒絕嘗試以該服務建立新工作階段的用戶端，直到一或多個作用中工作階段到期或由用戶端所取消為止。 用戶端在服務中可以擁有多個工作階段，而且會對該限制計數每個工作階段。
注意
當您使用具狀態的工作階段時，之前的段落就沒有作用。 如需詳細瞭解具狀態的工作階段，請參閱如何為安全工作階段建立安全內容權杖。
若要避免這個情況，請設定 SecurityBindingElement 類別的 SecurityBindingElement 屬性，以設定作用中工作階段數的上限和工作階段的最長存留時間。