為了執行需特定權限的操作，Microsoft ASP.NET 應用程式能夠模擬目前使用者的安全環境或是模擬呼叫它們的程序。雖然模擬環境能夠提供多種用途 (例如減少必要 authentication 的數量)，但是擁有高度權限的程式會為整個系統的安全帶來不必要的危險。如果攻擊者利用程式中的另一個弱點，而此程式正在另一個安全環境中執行，則攻擊者能夠執行所有未授權的操作，並擁有與之對應的權限。

範例 1：以下程式碼範例說明使用 WindowsIdentity.Impersonate() 方法模擬憑證的典型方式。

using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();

Example 1 中的程式碼模擬目前使用者的安全環境，並使用此安全環境執行一個需權限的操作。呼叫 DoSecuritySensitiveTasks() 之後，程式碼企圖還原原始的安全環境，但是如果 DoSecuritySensitiveTasks() 拋出一個異常狀況，將永遠不會呼叫 Undo() 方法，而程式也將持續使用模擬的安全環境。

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseCookiePolicy() 方法將 Cookie 原則中介軟體新增到中介軟體管道，進而允許自訂 Cookie 原則。當以錯誤的順序指定時，程式設計師聲明的任何 Cookie 原則將被忽略。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseHttpsRedirection() 方法將 HTTPS 重新導向中介軟體新增到中介軟體管道，進而允許將不安全的 HTTP 要求重新導向到安全的 HTTPS 要求。如果以錯誤的順序指定，則在透過重新導向之前列出的中介軟體處理要求之前，不會發生有意義的 HTTPS 重新導向。這將允許應用程式在重新導向到安全 HTTPS 連線之前處理 HTTP 要求。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

未依正確順序新增到中介軟體管道的 ASP.NET Core 中介軟體將無法依預期般執行，進而使應用程式可能面臨各種安全問題。

範例 1：UseHttpLogging() 方法將 HTTP 記錄中介軟體新增到中介軟體管道，進而允許記錄中介軟體元件。當以錯誤的順序指定時，在呼叫 UseHttpLogging() 之前將不會記錄新增到管道的任何中介軟體。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

範例 2：UseWC3Logging() 方法將 W3C 記錄中介軟體新增到中介軟體管道，進而允許記錄中介軟體元件。當以錯誤的順序指定時，在呼叫 UseWC3Logging() 之前將不會記錄新增到管道的任何中介軟體。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

將憑證驗證模式設為 None 會停用整個憑證驗證過程，這會使應用程式暴露於 Man-in-the-Middle 攻擊之下。生產環境中永遠不應使用此模式。

Cookie 常用來儲存使用者的重要資訊，比如個人資訊、Authentication 標記以及作業的歷史資訊。如果此資訊是以純文字方式儲存，那麼任何人只要能夠存取與應用程式互動的機器，都能夠存取儲存在 cookie 中的資訊。更糟糕的是，如果攻擊者可以隨意修改 cookie 中的資料，他們便能夠偽造提供給應用程式的資訊，有可能改變系統的運作方式以對他們有利。

在許多情況下，應用程式可以根據所在的環境來驗證由 cookie 提供的輸入，但 ASP.NET 的驗證框架提供了一個非常好的方法，可保護 cookie 的內容並驗證 cookie 未遭到非期望的修改。如不使用此方法，想要建立所有輸入都經過驗證的高層級信任是非常困難、甚至是不可能的。

可設定 ASP .NET 應用程式來產生除錯二進位程式。這些二進位程式提供了詳細的除錯訊息，不應該在生產的環境中使用。<compilation> 標籤的 debug 屬性定義編譯後的二進位程式是否應包含除錯資訊。

使用除錯二進位程式會使應用程式提供許多有關其本身的資訊給使用者。除錯二進位程式只能用於開發或測試的環境中，如果將它們部署在生產的環境中，會有安全上的風險。攻擊者可能利用這些從除錯輸出得到的額外資訊，來發動針對架構、資料庫或應用程式所使用的其他資源的攻擊。