如果使用 Blaze DS 來記錄所有無法預期的事件，services-config.xml 描述符號檔案會指定「記錄」XML 元素以描述記錄的不同內容。內容將與下列相似：

範例 1：

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

此 target 標籤有一個名為 level 的選擇性屬性，由它來指示記錄層級。如果除錯層級設定的層級過於詳細，應用程式可能會將敏感資料寫入記錄檔案。

Format String 弱點會在以下情況中出現：

1.資料從不可信賴的來源進入應用程式。



2.資料作為 Format String 引數傳送到函數，如 sprintf()、FormatMessageW() 或 syslog()。
範例 1：以下程式碼會使用 snprintf() 將指令行引數複製到緩衝區內。

int main(int argc, char **argv){
	char buf[128];
	...
	snprintf(buf,128,argv[1]);
}

這段程式碼允許攻擊者查看堆疊的內容，並使用包含一連串的格式化指示的指令行引數來寫入堆疊。攻擊者可能透過提供更多格式化指令 (例如 %x) 從堆疊讀取，然後函數會取得即將格式化的引數。(在此範例中，函數沒有取得即將格式化的引數。)透過使用 %n 格式化指令，攻擊者可能寫入堆疊，導致 snprintf() 將輸出的位元組數寫入到指定的引數 (而不是如預期從引數讀取值)。這種攻擊的一種繁瑣複雜的形式會使用四條交錯的輸入來完全控制堆疊中一個指標的數值。

範例 2：透過提供可控制記憶體中讀取或寫入位置的格式指令，某些實作甚至可以更輕鬆地執行更進階的攻擊。為 glibc 而寫的以下程式碼中顯示了這種指示的範例：

	printf("%d %d %1$d %1$d\n", 5, 9);

此程式碼會產生以下輸出：

5 9 5 5

使用 half-writes(%hn) 來準確地控制記憶體中任意的 DWORDS 的可能性同樣存在，這會大大地降低執行一次攻擊所必須的複雜度，如果不這樣，就會要求四條交錯的輸入，如 Example 1 中所提到的一樣。

範例 3：簡單的格式字串弱點經常是由於看似無害的捷徑。使用一些這樣的執行方式是非常地根深地固，以致於程式設計師可能都不會意識到他們所使用的函數需要一個 Format String 參數。

例如，syslog() 函數有時候以如下形式使用：

	...
	syslog(LOG_ERR, cmdBuf);
	...

因為 syslog() 的第二個參數是個 Format String，所以任何包含在 cmdBuf 內的格式化指令都會被解譯，如 Example 1 中所述。

以下程式碼顯示了 syslog() 的正確使用方式：

	...
	syslog(LOG_ERR, "%s", cmdBuf);
	...

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

在此案例中，錯誤建構的 Format String 會導致程式從分配記憶體邊界以外的位置存取值。

範例 1：以下程式碼從堆疊讀取任意值，因為格式規範的數值與傳送到函數的引數數值不同。

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

Buffer overflow 可能是軟體安全性弱點最為人知的一種形式。大部分軟體開發人員都知道什麼是 Buffer overflow 弱點，但傳統和新開發的應用程式仍常遭到 Buffer overflow 攻擊。此問題的部份原因是，發生 Buffer overflow 的方式很多，部分原因是人們常常用不恰當的方式來防範 Buffer overflow。

在典型的 Buffer overflow 攻擊中，攻擊者會將資料傳送到程式，而程式會將其儲存在一個較小的堆疊緩衝區內。結果就是呼叫這個堆疊的資訊超出了它的邊界，其中包括函數的回傳指標。該資料設定了回傳指標的值，當函數回傳時，會將控制傳送到攻擊者資料所包含的惡意程式碼。

這類型的堆疊 Buffer overflow 在一些平台和開發社群中仍然很常見，但卻還有多種其他類型的 Buffer overflow，包括堆積 Buffer overflow 和差一錯誤 (off-by-one-error) 等等。有許多優秀的著作提供了關於堆疊 Buffer overflow 如何攻擊的具體資訊，包括 Building Secure Software[1]、Writing Secure Code[2]和 The Shellcoder's Handbook[3]。

在程式碼層級，會發生 Buffer overflow 弱點通常是因為程式設計師的假設被推翻。C 和 C++ 中的很多記憶體處理函數都沒有執行邊界值檢查，並會輕易地超出操作中緩衝區被配置的邊界值。甚至如 strncpy() 的範圍函數，使用不正確時也會引起弱點。大多數 Buffer overflow 弱點的根本原因，都是緩衝區的處理，加上對資料的大小或組成假設錯誤。

在此案例中，錯誤建構的 Format String 會導致程式以錯誤的方式轉換資料值，或從分配記憶體邊界以外的位置存取值。

範例 1：以下程式碼錯誤地使用 %d 格式規範從浮點數轉換 f。

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

常見的試算表處理器 (例如 Apache OpenOffice Calc 和 Microsoft Office Excel) 支援功能強大的公式運算，這可能允許攻擊者控制試算表以便在基礎系統上執行任意指令或洩露試算表上的敏感資訊。

例如，攻擊者可能會注入下列裝載做為 CSV 欄位的一部分：=cmd|'/C calc.exe'!Z0。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源，則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。

範例 1：以下範例顯示使用未經處理的使用者控制的資料產生 CSV 回應的 Spring 控制項：

    @RequestMapping(value = "/api/service.csv")
    public ResponseEntity<String> service(@RequestParam("name") String name) {

        HttpHeaders responseHeaders = new HttpHeaders();
        responseHeaders.add("Content-Type", "application/csv; charset=utf-8");
        responseHeaders.add("Content-Disposition", "attachment;filename=file.csv");

        String data = generateCSVFor(name);

        return new ResponseEntity<>(data, responseHeaders, HttpStatus.OK);
    }

惡意應用程式會叫用不安全的 PreferenceActivity，並為其額外提供 :android:show_fragment 意圖以使其載入任意類別。 惡意應用程式會讓 PreferenceActivity 載入易受攻擊應用程式的任意 Fragment (一般在未匯出的活動內載入)，從而將其暴露給攻擊者。

範例 1： 下列程式碼無法實作檢查以確認僅載入預期片段。

@Override
public static boolean isFragmentValid(Fragment paramFragment)
{
    return true;
}

框架欺騙弱點會在以下情況中出現：

1. 資料從一個不可信賴的來源進入 Web 應用程式。

2. 此資料將用作 iframe URL，且無需進行驗證。

這樣一來，攻擊者可能會控制將轉譯成內嵌框架的內容。透過修改框架 URL 以指向惡意網站，可能會嘗試執行釣魚攻擊來竊取使用者資訊 (包括認證或其他敏感資料)。假設基礎網域可以信任 - Salesforce.com，受害者將信任該頁面並提供所有要求的資訊。

範例 1：在以下程式碼範例中，iframesrc URL 參數將直接用作 apex:iframe 目標 URL。

<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>

這樣一來，如果攻擊者為受害者提供設為惡意網站的 iframesrc 參數，則框架將使用惡意網站的內容進行轉譯。

<iframe src="http://evildomain.com/">

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

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

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

若將存取權或 BigQuery 角色授予特殊主體類型 (例如 allUsers 和 allAuthenticatedUsers)，任何人都可以存取敏感資料。

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

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

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

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

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

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

DNSSEC 透過提供使用數位簽章進行 DNS 回應驗證的能力來防止 DNS 假冒。Cloud DNS 網域的 DNSSEC 未啟用。

範例 1：以下範例顯示一個 Terraform 組態，其透過將 dnssec_config 區塊的 state 設定為 off，來停用 Cloud DNS 網域上的 DNSSEC。

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    state = "off"
    ...
  }
...
}

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

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

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

將 Cloud KMS CryptoKey 角色授予 allUsers 或 allAuthenticatedUsers 後，任何人都可以存取敏感資料。

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

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

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

資料庫備份對於防止資料遺失或損毀至關重要。所以，應明確設定並啟用 Cloud SQL 資料庫執行個體的自動備份功能。

範例 1：以下範例顯示一個 Terraform 組態，其透過將 enabled 設定為 false 來停用資料庫執行個體備份組態。

resource "google_sql_database_instance" "database_instance_demo" {
  ...
  settings {
    backup_configuration {
      enabled = false
      ...
    }
  }
}

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

依預設，Terraform 會部署只接受來自私有 IP 位址連線的 Google Cloud SQL Database 執行個體。選用的 Authorized Networks 設定定義了可接受的公用 IP 位址範圍。

範例 1：以下 Terraform 組態在 authorized_networks 區塊中將 value 設為 0.0.0.0/0。/0 的 CIDR 區塊會接受來自 0.0.0.0 和 255.255.255.255 之間任何 IP 位址的連線。

resource "google_sql_database_instance" "db-demo" {
  ...
  settings {
  ...
    ip_configuration {
    ...
      authorized_networks {
        name  = "any ip"
        value = "0.0.0.0/0"
      }
    ...
    }
    ...
  }
  ...
}

將 Cloud Storage 角色授予 allUsers 或 allAuthenticatedUsers 後，任何人都可以存取敏感資料。

權限管理不善會增加未經授權存取或限制資料遭到修改的風險。

為了定義存取儲存貯體和儲存貯體中物件的使用者權限，Google Cloud Storage 提供了兩個系統：存取控制清單 (ACL) 和 Identity and Access Management (IAM)。IAM 可以在整個 Google Cloud 中使用，但只有 Cloud Storage 支援 ACL。啟用 Uniform Bucket-level Access 會阻止 ACL 授予權限。這可確保 IAM 是管理 Google Cloud 資源所有存取控制的唯一系統。

範例 1：以下 Terraform 組態透過將 uniform_bucket_level_access 設為 false，來允許使用 ACL 和 IAM 授予對儲存貯體的存取權限。

resource "google_storage_bucket" "bucket-demo" {
...
  uniform_bucket_level_access = false
...
}

IAM 型存取控制可減少人為錯誤，並提高效率。啟用 OS Login 後，會允許使用 IAM 角色來自動化 Linux 帳戶的生命週期管理，以存取同一專案或組織中的所有 Compute Engine 執行個體。

範例 1：以下範例顯示一個 Terraform 組態，其透過將 metadata 引數中的 enable-oslogin 設定為 false 來停用使用 IAM 角色管理 SSH 存取。

resource "google_compute_instance" "compute-instance-demo" {
  ...
  metadata = {
    enable-oslogin = false
    ...
  }
  ...
}