若缺乏稽核記錄，將會限制偵測和回應安全相關事件的能力，並阻礙取證調查。

削弱記錄控功能的組態設定包括但不限於：
- 蓄意停用稽核記錄
- 免除記錄特定使用者、群組或程序的動作
- 未充分保護記錄完整性
- 未啟用選用稽核記錄
- 降低記錄採樣率

Terraform 組態設定了虛擬機器子網路，卻未指定記錄選項。這些記錄包含用於網路監控、取證、即時安全分析和費用最佳化的寶貴資料。

權限管理不善會增加未經授權存取或資料遭到修改的風險，也會減弱服務可用性。

服務帳戶是應用程式或虛擬機器 (而非人) 所使用的特殊 Google 帳戶，其使用敏感權限來執行自動化流程或代表一般使用者發出 API 要求。服務帳戶應加以審慎管理、控制及稽核，以便可以獲得信任。將服務帳戶角色指派給通常代表一個人的 IAM 使用者，將會削弱安全控制機制。

未能封鎖不需要的網路流量，將會擴大雲端服務的受攻擊面。開放與公眾互動的服務會受到惡意實體幾乎連續的掃描和探測。

未針對靜態資料啟用客戶自管加密金鑰 (CMEK)。

依預設，Google Cloud 使用隨機產生的資料加密金鑰 (DEK) 來加密靜態資料。CMEK 功能允許組織使用自己選擇的加密金鑰來加密 DEK。這讓組織可以妥善控制和記錄加密過程。

因此，CMEK 通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰
- 防篡改硬體安全性模組

未針對靜態資料啟用客戶自管加密金鑰 (CMEK)。

依預設，Google Cloud 使用隨機產生的資料加密金鑰 (DEK) 來加密靜態資料。CMEK 功能允許組織使用自己選擇的加密金鑰來加密 DEK。這讓組織可以妥善控制和記錄加密過程。

因此，CMEK 通常會納入解決方案的一部分，可滿足包括但不限於以下需求：
- 敏感資料存取的稽核記錄
- 資料落地
- 取代、停用或銷毀金鑰
- 防篡改硬體安全性模組

URL 對應是一組規則，用於將傳入 HTTP(S) 要求路由到特定的後端服務。依預設，URL 對應接受未加密和不安全的連線。這類的連線會將資料暴露於未經授權存取、潛在竊取和竄改的風險。

範例 1：以下範例顯示一個 Terraform 組態，其透過將 https_redirect 設為 false 來定義 URL 對應，以允許用戶端使用 HTTP 進行通訊。

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

DNSSEC 透過提供使用數位簽章進行 DNS 回應驗證的能力來防止 DNS 假冒。然而，任何使用 SHA-1 的 DNSSEC 簽署演算法都容易受到風險不斷增加的攻擊。與數位簽章一起使用時，SHA-1 就不會被視為安全雜湊演算法。

範例 1：以下範例顯示使用不安全簽署演算法 rsasha1 啟用 DNSSEC 的 Terraform 組態。

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

GKE 支援兩種叢集網路模式：路徑導向和 VPC 原生。VPC 原生叢集使用別名 IP 位址範圍，將流量從節點中的一個 Pod 路由傳送到另一個 Pod。如此可允許將以 IP 為主的精確原則和防火牆規則用於 Pod。相較之下，整個節點是路徑導向叢集中最精細的控制等級。

範例 1：以下範例 Terraform 組態透過將 networking_mode 設定為 ROUTES 而不啟用 VPC 原生叢集。

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}

X-XSS-Protection 是由 Microsoft 引入的 HTTP 標頭，後來由其他瀏覽器所採用。這旨在協助阻止 Cross-Site Scripting 攻擊成功，但不慎導致弱點的情況，使得安全網站易受攻擊[1]。因此，不應在舊版 Internet Explorer 中使用此標頭，並且應透過將標頭設定為 0 將其停用。

範例 1：以下錯誤地配置了 Express 應用程式中的 Helmet 中介軟體，以針對所有版本的 Internet Explorer 啟用此標頭：

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

MIME 攔截是檢查位元組串流內容的做法，可推算其中所包含資料的檔案格式。

如果未明確停用 MIME 攔截，攻擊者可以操縱某些瀏覽器以非預期的方式解譯資料，進行導致出現 Cross-Site Scripting 攻擊。對於可能包含使用者可控內容的每個頁面，您應該使用 HTTP 標頭 X-Content-Type-Options: nosniff。

範例 1：以下程式碼會將受 Spring Security 保護的應用程式設定為停用 MIME 攔截保護：

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

出現以下情況時，就會發生編譯器最佳化錯誤：

1. 機密資料儲存在記憶體中。

2. 藉由覆寫記憶體內容的方式，來從記憶體清除機密資料。



3. 來源程式碼藉由使用最佳化編譯器來編譯，其會將覆蓋相關內容的函數做為一個無效儲存識別出來並進行移除，因為記憶體之後不會使用這個儲存。
範例 1：以下程式碼會從使用者讀取密碼、使用此密碼連線到後端主機，然後嘗試使用 memset() 來清除記憶體中的密碼。

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

如果範例中的程式碼被逐字地執行，那麼它就能正確地執行；但如果程式碼是使用最佳化編譯器進行編譯 (如 Microsoft Visual C++(R) .NET 或者 GCC 3.x)，那麼 memset() 的呼叫會被當作一個無效儲存清除，因為 pwd 的緩衝區在它的數值被覆蓋之後不會再次被使用 [2]。因為緩衝區 pwd 包含一個敏感值，所以如果資料經常被留在記憶體中，應用程式就會容易受到攻擊。如果攻擊者能夠存取記憶體正確的區域，他們就能使用復原後的密碼來取得對系統的控制。

為了防止攻擊者得到系統的機密，覆蓋記憶體中操作的敏感資料 (如密碼或密鑰) 是種常見的作法。然而，隨著最佳化編譯器的到來，程式不會一直如指示的那樣僅僅按照來源程式碼執行。在此範例中，因為 memset() 的呼叫被寫入記憶體之後不會被使用，所以編譯器將這個呼叫解譯為一段 Dead Code；而這樣做實際上很顯然會引起一個安全問題。這裏的問題是，許多編譯器和許多程式語言並沒有在其提高效率時考慮到此問題和其他安全問題。

攻擊者通常會使用核心傾印或執行期間機制來利用這種類型的弱點，藉此存取某個特定的應用程式所使用的記憶體，並恢復機密資訊。一旦攻擊者存取到機密資訊，盜取更多的系統資訊就相對簡單了，並有可能危及到這個應用程式涉及到的其他資源。

若陣列邊界檢查需要計算違反規定的指標並確定指標已超出邊界，某些編譯器會最佳化該檢查，並認定程式設計師絕不會蓄意建立違反規定的指標。

範例 1：

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

運算 buf + len 大於 2^32，因此產生的值小於 buf。但是，由於指標的算數運算溢位是未定義的行為，因此某些編譯器會假設 buf + len >= buf，並最佳化封裝檢查。此最佳化操作的結果是，此區塊後的程式碼很容易出現 Buffer overflow。

Django 應用程式會暴露 static files 應用程式的 serve 視圖，此視圖並非專用於在生產環境中部署。根據 Django 說明文件：

「static files 工具主要用於協助取得已在生產中成功部署的靜態檔案。這通常是指單獨、專用的靜態檔案伺服器，於本機開發時，此伺服器的運作成本極高。因此，靜態檔案應用程式隨附臨時應急的協助程式視圖，用來在開發期間於本機執行檔案。

僅當 DEBUG 為 True 時，此視圖才有效。

這是因為，此視圖非常低效且可能不安全。這僅適用於本機開發，絕不能用於生產中。」

包含敏感資訊或提供具有特殊權限的功能的應用程式資源通常面臨更大的攻擊風險。在偵察階段，攻擊者會嘗試尋找此類檔案和目錄。針對此類資源使用可預測的命名架構會讓攻擊者更容易找到這些資源。處理敏感功能 (例如，驗證、管理工作或私人資訊處理) 的所有應用程式資源都必須得到充分保護，以免被發現。

範例 1：在以下範例中，admin 應用程式部署在可預測的 URL 中：

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

負責儲存資料的資源必須與實作應用程式功能的資源分開。程式設計師必須在建立暫存或備份資源時小心謹慎。

多數 Web 應用程式使用工作階段識別碼來識別各使用者，該識別碼通常儲存在 Cookie 中，並在伺服器與網路瀏覽器間公開傳輸。


未在 Cookie 中儲存工作階段識別碼的應用程式，有時會傳輸識別碼做為 HTTP 要求參數或 URL 的一部份。接受 URL 中指定的工作階段識別碼，容易讓攻擊者執行 Session Fixation 攻擊。

將工作階段識別碼置於 URL，也可能會增加 Session Hijacking 對應用程式成功攻擊的機會。當攻擊者控制受害者啟用的工作階段或工作階段識別碼時，Session Hijacking 便會發生。網路伺服器、應用程式伺服器及 Web 代理伺服器通常會儲存要求的 URL，這是種常見的作法。若 URL 中包含工作階段識別碼，也會記錄這些識別碼。增加工作階段識別碼檢視及儲存位置的數量，將增加攻擊者危及這些識別碼的機會。

如果您使用 Tomcat 來執行 authentication，Tomcat 部署描述符號檔案會指定「Realm」用於 Authentication。內容將與下列相似：

範例 1：

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

此 Realm 標籤有一個名為 debug 的選擇性屬性，由它來指示記錄層級。數字越大，記錄的訊息就越詳細。如果除錯層級設定過高，Tomcat 會把所有的使用者名稱和密碼以純文字方式寫入至記錄檔中。Tomcat JAASRealm 相關的除錯訊息的臨界值是 3 (3 或更高表示有問題，2 或更低表示正常)，但此臨界值可能會因 Tomcat 提供不同的 realm 類型而有所不同。

在使用 Web 架構，例如 Struts 或 Spring (使用動作或 Servlet 對 JSP 發出請求) 所建立的應用程式中，直接存取 Java Server Page (JSP)，可能會導致無法處理的異常以及系統資訊洩露。執行或設定不當的應用程式伺服器已被用來洩露原始碼詳細資料，使用的手段則包括 http://host/page.jsp%00 或 http://host/page.js%2570 等精心設計的要求。更糟的是，如果應用程式允許使用者上傳任意檔案，攻擊者可能使用此機制，上傳以 JSP 型式製作的惡意程式碼，並要求已上傳頁面，以在伺服器上執行惡意程式碼。

範例 1：以下範例說明建構不良的安全性限制，明確允許角色名稱中含有「*」直接存取 JSP，因此，這表示所有使用者都可以存取對應的 Web 資源。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

相同的安全性角色並無意義，因為只會套用特定安全性角色的最後定義。
範例 1：在 web.xml 檔案中的項目定義了兩個 admin 角色。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

相同的 Servlet 對應是沒有意義的，因為在多個 Servlet 對應中使用相同 URL 模式時，只會套用最後一個項目。

範例 1：在以下範例中，兩個不同的 Servlet 對應中使用 URL 模式 /servletA/*。

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>