ASP.NET W3Clogger.loggingFields 可以設定為允許記錄敏感資料，例如私人資訊和系統資訊。
此資料可能包含與 HTTP 要求和 HTTP 回應相關的敏感資訊，例如用戶端/伺服器 IP、伺服器連接埠、標頭 cookie 和存取伺服器的經過驗證的使用者名稱。

萬一有資料外洩的情況，對手可以使用此資訊來：

- 竊取敏感資訊或冒充具有更高權限的使用者。
- 探索內部伺服器，獲得對受限資源的未授權存取。
- 設計攻擊並將重點放在利用針對所偵測伺服器報告的已知弱點


範例 1：以下程式碼顯示已停用驗證的控制項中的動作方法。

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;

    ... )

Example 1 顯示如何使用 All 旗標，將 W3Clogging 設定為記錄 Http 要求中的所有可能欄位，例如 ClientIpAddress、ServerName、ServerIpAddress、ServerPort、UserName 和 Cookie。

FormsAuthentication.RedirectFromLoginPage() 方法會發出 authentication 許可證，此許可證可讓使用者在特定的一段期間內維持驗證的身分。若將該方法的第二個參數設為 false，它會發出一個臨時的 authentication 許可證，其有效期在 web.config 中配置。若將第二個參數設為 true，此方法會發出 Persistent Authentication 許可證。在.NET 2.0 中，許可證的有效期為在 web.config 中配置的值，但在.NET 1.1 中，Persistent Authentication 許可證的有效期有個不可思議的預設值 － 50 年！

允許 Persistent Authentication 許可證長時期的存在，會讓使用者和系統容易遭遇以下幾種攻擊：

對那些沒有登出的使用者，Persistent Authentication 許可證延長了其暴露在階段作業劫持攻擊的時間。

Persistent Authentication 許可證增加了攻擊者猜中有效的階段作業識別碼的機率。

當攻擊者成功地劫持了使用者的階段作業後，這將使攻擊者有更多的時間來盜取資訊。

將 useUnsafeHeaderParsing 設定為 true 會鬆懈 HTTP 表頭的處理過程。過度允許的 HTTP 表頭驗證規則會導致易受攻擊的應用程式遭受各種攻擊。



明確的說，當這個屬性設為 False 時，下列的驗證規則就不再強制執行：

行尾程式碼中，請使用 CRLF；不可單獨使用 CR 或 LF。

標頭名稱中不可有空白。

如果多重狀態行存在，所有額外的狀態行將被視為異常的標頭名稱/值對。

狀態行除了狀態碼之外，還必須有狀態描述。

標頭名稱內不可有非 ASCII 字元。不管屬性為 True 或 False，都會執行驗證。

如發生違反通訊協定事項，將拋出 WebException 例外狀況，其狀態會設為 ServerProtocolViolation。如果 UseUnsafeHeaderParsing 屬性設為 True，則會忽略驗證錯誤。

將屬性設定為 True 有其隱含的安全問題，因此除非伺服器必須具備回溯相容性，否則不應如此設定。


範例 1：在以下範例中，useUnsafeHeaderParsing 設定為 true。

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest  useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...

在 ASP.NET，檢視狀態是一種在回傳 (postback) 間持續網路表單狀態的機制。檢視狀態中儲存的資料不受信任，因為沒有防止重複進行攻擊的機制。當停用檢視狀態訊息 Authentication 檢查時，信任檢視狀態將更為危險。停用此項檢查，會讓攻擊者對檢視狀態中儲存的資料任意進行變更，並製造對信任檢視狀態的程式碼的攻擊機會。攻擊者可使用這種錯誤來破解 Authentication 檢查或修改項目定價。

ASP.NET MVC 在表單中新增防偽造權杖，並在控制項中對該防偽造權杖進行驗證，從而提供便利的方式來更好地保護應用程式抵禦跨網站偽造要求攻擊。此權杖在使用時，通常做為隱藏表單欄位包括在內，並在提交表單時進行驗證，如此可以提高要求來自您的應用程式 (而非偽造) 的可能性。

以下控制項程式碼不含針對跨網站偽造要求攻擊的內建防禦：

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}

ASP.NET MVC 在 HTML 表單中新增防偽造權杖，並在控制項中對該防偽造權杖進行驗證，從而提供便利的方式來更好地保護應用程式抵禦跨網站偽造要求攻擊。此權杖在使用時，通常做為隱藏表單欄位包括在內，並在提交表單時進行驗證，如此可以提高要求來自您的應用程式 (而非偽造) 的可能性。

一般而言，程式設計人員應將此防偽造權杖包括在內，因為這會提高針對應用程式使用惡意指令碼的代價。

範例 1：以下 Razor 程式碼會在產生的 HTML 中建立表單，但不含針對跨網站偽造要求攻擊的內建防禦：

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
  // ... form elements
}

Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:

@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
  // ... form elements
}

NSURLConnectionDelegate.connection(_:willSendRequestFor:) 委派方法允許委派立即就連線驗證做出明智的決策。如果委派執行此方法，則無需執行 NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) 或 NSURLConnectionDelegate.connection(_:didReceive:)。事實上，不會叫用這些方法，因此將會忽略對其進行的任何安全檢查。