Unmanaged 程式碼
更新：2007 年 11 月
某些程式庫程式碼需要呼叫進入 Unmanaged 程式碼 (例如，Win32 之類的機器碼 API)。由於這表示程式碼已經超出 Managed 程式庫的安全性界線之外，因此需要格外謹慎。如果您的程式碼為安全性中性，則您的程式碼和任何呼叫它的程式碼，都必須擁有 Unmanaged 程式碼使用權限 (指定了 UnmanagedCode 旗標的 SecurityPermission)。
然而，讓您的呼叫端擁有如此強大的使用權限通常是不太合理的。在這類情況下，您的受信任程式碼可以扮演中介者的角色，如同設定包裝函式程式碼的安全性中說明的 Managed 包裝函式或程式庫程式碼。如果基礎 Unmanaged 程式碼功能安全無虞，就可直接將它公開，否則便須先執行適當的使用權限檢查 (需求)。
如果您的程式碼呼叫進入 Unmanaged 程式碼，但是您不想讓您的呼叫端擁有存取 Unmanaged 程式碼的使用權限，您就必須判斷該權限。判斷提示會封鎖您框架上的堆疊查核行程。這個過程中您必須小心，不要製造安全性漏洞。通常，這代表您必須要求呼叫端的適當使用權限，然後再使用 Unmanaged 程式碼執行使用權限允許的動作。在某些情況下 (例如，取得當天時間的功能)，Unmanaged 程式碼可以直接公開給呼叫端，而不需執行任何安全性檢查。不論是哪一種狀況，可進行判斷的任何程式碼都必須承擔維護安全性的責任。
由於任何可以提供進入機器碼之程式碼路徑的 Managed 程式碼都是惡意程式碼的潛在目標，因此在判斷哪一個 Unmanaged 程式碼可以放心使用時，必須要非常小心。一般來說，Unmanaged 程式碼不應直接公開給部分受信任的呼叫端。針對在可由部分受信任程式碼呼叫的程式庫中使用 Unmanaged 程式碼的安全狀況進行評估時，有兩個主要考量事項：
功能。Unmanaged API 是否提供不允許呼叫端執行具有潛在危險性作業的功能？程式碼存取安全性利用使用權限來強制使用資源的存取權，因此請考量 API 是否使用檔案、使用者介面或執行緒處理，或者它是否公開受保護的資訊。如果是，包裝它的 Managed 程式碼就必須要求必要的使用權限，然後才能允許您將它輸入。此外，在沒有使用權限的保護時，記憶體的存取必須限制為嚴格的型別安全 (Type Safety)。
參數檢查。一般的攻擊會將未預期的參數傳遞到公開的 Unmanaged 程式碼 API 方法，試圖使它們不按規格作業。使用超出範圍的索引或位移 (Offset) 值的緩衝區滿溢 (Buffer Overrun) 是這種攻擊的典型範例，而可能利用基礎程式碼錯誤的任何參數也是。因此，即使對於部分受信任呼叫端而言，Unmanaged 程式碼 API 功能上安全無虞 (在執行必要的需求之後)，Managed 程式碼也必須徹底檢查參數的有效性，確保惡意程式碼不可能利用 Managed 程式碼包裝函式層發出錯誤的呼叫。